[E1000-devel] [PATCH] e1000e: balance semaphore put/get for 82573

2013-07-12 Thread akepner
Hi e1000e-devel; Steven (cc-ed) noticed an imbalance in semaphore put/get for 82573-based NICs. Don't we need something like the following (untested) patch? From: Steven La Acked-by: Arthur Kepner --- diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e

Re: [E1000-devel] e1000e: avoid NULL pointer deref in e1000_print_hw_hang()

2013-03-20 Thread akepner
(Resending - the previous version was against our local tree, not the upstream tree.) If an e1000e interface is brought down, and subsequently 'print_hang_task' is run we'll dereference a NULL 'buffer_info' pointer and crash with something like this: Mar 19 13:20:27 BUG: unable to handle ke

Re: [E1000-devel] [patch] ixgbe: in shutdown, do netif_running() under rtnl_lock

2013-03-12 Thread akepner
Hi e1000-devel; I sent a patch (same subject line as this mail) last Friday to both e1000-devel, and netdev. Could you have a look at it, and give it an ack, or nak? Thanks. -- Arthur -- Symantec Endpoint Protec

[E1000-devel] [patch] ixgbe: in shutdown, do netif_running() under rtnl_lock

2013-03-08 Thread akepner
During shutdown it's possible for __dev_close() (which holds rtnl_lock) to clear the __LINK_STATE_START bit, and for ixgbe to then read that bit (without holding rtnl_lock), and then not fail to free irqs, etc. The result is a crash like this: [ cut here ] kernel BUG a

Re: [E1000-devel] pci probe of 82574 fails

2013-01-29 Thread akepner
On Fri, Jan 25, 2013 at 08:25:17PM +, Ronciak, John wrote: > This could be BIOS configuration as well. Check the BIOS version as Tushar > says but also look at how you have the device/slot configured in the BIOS. > The "probe of :07:00.0 failed with error -2" is seen with only a few sy

Re: [E1000-devel] pci probe of 82574 fails

2013-01-25 Thread akepner
On Fri, Jan 25, 2013 at 08:25:17PM +, Ronciak, John wrote: > This could be BIOS configuration as well. Check the BIOS version as Tushar > says but also look at how you have the device/slot configured in the BIOS. > Will double check on bios version and get back to you both. But would you

[E1000-devel] pci probe of 82574 fails

2013-01-25 Thread akepner
We have seen some instances where the pci probe of a 82574 is failing like this: e1000e :07:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46 e1000e :07:00.0: setting latency timer to 64 alloc irq_desc for 92 on node 0 alloc kstat_irqs on node 0 e1000e :07:00.0: irq 92 for MSI/MSI-

Re: [E1000-devel] e1000e: ethtool -t fails when i/f is up

2012-12-10 Thread akepner
Ping! Any info about this one? -- Arthur -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on

Re: [E1000-devel] e1000e: ethtool -t fails when i/f is up

2012-11-16 Thread akepner
On Fri, Nov 16, 2012 at 04:27:25PM -0800, Jesse Brandeburg wrote: > On Fri, 16 Nov 2012 14:58:13 -0800 akepner wrote: > > > With e1000e (versions 1.2.20, and 2.1.4) we've noticed that the > > ethtool selftest fails with a miscompare when the interface is > > up

[E1000-devel] e1000e: ethtool -t fails when i/f is up

2012-11-16 Thread akepner
With e1000e (versions 1.2.20, and 2.1.4) we've noticed that the ethtool selftest fails with a miscompare when the interface is up, but succeeds when it's down: [admin@oak-sh317 ~]# ifconfig lan0_0 up [admin@oak-sh317 ~]# ethtool -t lan0_0 The test result is FAIL The test extra info: Register t

Re: [E1000-devel] ixgbe 3.7.21: NULL skb deref in ixgbe_clean_rx_irq_ps()

2012-07-12 Thread akepner
On Thu, Jul 12, 2012 at 11:21:46AM -0700, Alexander Duyck wrote: > . > It seems like it might be some sort of memory corruption. In order to > get into that state the DD bit has to be set for the descriptor and the > skb would have to be NULL. > > What part is it you are running this on? Is

[E1000-devel] ixgbe 3.7.21: NULL skb deref in ixgbe_clean_rx_irq_ps()

2012-07-11 Thread akepner
Using the 3.7.21 version of the ixgbe driver we can reliably produce a crash with this signature: BUG: unable to handle kernel NULL pointer dereference at 006c IP: [] ixgbe_poll+0x9df/0x1710 [ixgbe] PGD 814c7b067 PUD 8074dd067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/device