On 01/07/2014 09:17 PM, Neil Horman wrote:
> On Tue, Jan 07, 2014 at 11:42:24AM +0800, Jason Wang wrote:
>> On 01/06/2014 08:42 PM, Neil Horman wrote:
>>> On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote:
Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit().
>>>
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Julia Lawall
> Sent: Tuesday, January 07, 2014 9:00 AM
> To: Kirsher, Jeffrey T
> Cc: kernel-janit...@vger.kernel.org; Brandeburg, Jesse; Allan, Bruce W;
> Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V
Hi Don, Scott and Shannon,
Many thanks for all your help, ethtool -i is now showing the correct
information.
Very much appreciated.
Martin
On 2014-01-07 20:07, Nelson, Shannon wrote:
>> -Original Message-
>> From: Martin Wheldon [mailto:martin.whel...@greenhills-it.co.uk]
>> Sent: Tuesd
> -Original Message-
> From: Martin Wheldon [mailto:martin.whel...@greenhills-it.co.uk]
> Sent: Tuesday, January 07, 2014 9:46 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] ixgbe master disable timeout
>
> Hi Don,
>
> A little tricky for me as this box only has
Hi Don,
A little tricky for me as this box only has 2 interfaces and both use
this driver,
I'm also 1.5 hours drive from it.
However modinfo shows the correct version.
swlb-cluster1 ~ # modinfo ixgbe
filename:
/lib/modules/2.6.32-5-amd64/kernel/drivers/net/ixgbe/ixgbe.ko
version:
Hey Martin,
That is strange? Just to sanity check did you:
rmmod ixgbe - to remove the old driver
lsmod | grep ixgbe - to make sure the old driver is gone
insmod ixgbe.ko - load the driver you just compiled
or
modprobe ixgbe - if you already installed the newer modules with make instal
Hi Don,
Many thanks for your swift reply. It's very much appreciated.
I thought that was the case, but was unable to confirm it. I've just
installed the latest version
ixgbe-3.19.1 on one of the systems.
However when I run on the old/new boxes it reports the same version:
swlb-cluster1 ~ # etht
Hey Martin,
The error you are seeing here is the driver disabling PCIe Master during the
reset path and the transaction pending bit not clearing while we waited for it.
We corrected a similar problem a few releases ago changing from a static
timeout value to more dynamicly configured. So yes
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, January 06, 2014 10:12 PM
> To: Rose, Gregory V
> Cc: e1000-devel@lists.sourceforge.net; Williams, Mitch A
> Subject: re: i40evf: main driver core
>
> Hello Greg Rose,
>
> The patch 5eae00c57f5e
On 1/5/2014 7:21 PM, Jason Wang wrote:
> Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
> will cause several issues:
>
> - NETIF_F_LLTX was forced for macvlan device in this case which lead extra
> lock
>contention.
> - dev_hard_start_xmit() was called with NULL
Hi,
I'm having problems with several Intel Corporation 82599EB 10-Gigabit
network adapters.
We are running quite a old version of the driver ixgbe-3.11.33
My question is after much googling would updating the driver fix this
issue?
# dmesg
[434482.555966] [ cut here ]
From: Julia Lawall
This driver does not need to adjust the power state on suspend, so the
call to pci_set_power_state in the resume function is a no-op. Drop it, to
make the code more understandable.
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |1 -
On 01/07/2014 07:44 AM, Julia Lawall wrote:
> On Tue, 7 Jan 2014, Alexander Duyck wrote:
>
>> A VF isn't a real device so it shouldn't really have the concept of a
>> power state. The power state for the device is controlled via the PF.
>> I suspect the fact that ixgbevf is modifying power state o
On Tue, 7 Jan 2014, Alexander Duyck wrote:
> A VF isn't a real device so it shouldn't really have the concept of a
> power state. The power state for the device is controlled via the PF.
> I suspect the fact that ixgbevf is modifying power state on resume is
> likely a bug.
Thanks for the inform
A VF isn't a real device so it shouldn't really have the concept of a
power state. The power state for the device is controlled via the PF.
I suspect the fact that ixgbevf is modifying power state on resume is
likely a bug.
Thanks,
Alex
On 01/07/2014 06:46 AM, Julia Lawall wrote:
> I was wonder
I was wondering why ixgbevf_suspend doesn't call pci_set_power_state? It
is called in the corresponding resume function, and most other PCI drivers
with a suspend functyion also call it in suspend.
thanks,
julia
--
Rapid
On Tue, Jan 07, 2014 at 11:42:24AM +0800, Jason Wang wrote:
> On 01/06/2014 08:42 PM, Neil Horman wrote:
> > On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote:
> >> Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit().
> >> The
> >> will cause several issues:
> >>
> >
From: Wei Yongjun
We had set the pci driver-specific data in i40evf_probe() as
a type of struct net_device, so we should use it as netdev
in i40evf_resume().
Signed-off-by: Wei Yongjun
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[...]
>>
>> +int dfwd_direct_xmit(struct sk_buff *skb, struct net_device *dev,
>> + void *accel_priv)
>> +{
>> +struct netdev_queue *txq;
>> +int ret = NETDEV_TX_BUSY;
>> +int index;
>> +
>> +BUG_ON(!dev->netdev_ops->ndo_dfwd_select_queue);
>> +index =dev->netde
19 matches
Mail list logo
