linux-stable.git/drivers/net/ethernet, branch v3.4.30

igb: release already assigned MSI-X interrupts if setup fails

2013-01-21T19:45:25+00:00

commit 52285b762b3681669215bf1d17ca6143448ab7d3 upstream.

During MSI-X setup the system might run out of vectors. If this happens the
already assigned vectors for this NIC should be freed before trying the
disable MSI-X. Failing to do so results in the following oops.

kernel BUG at drivers/pci/msi.c:341!
[...]
Call Trace:
 [] pci_disable_msix+0x3d/0x60
 [] igb_reset_interrupt_capability+0x27/0x5c [igb]
 [] igb_clear_interrupt_scheme+0x26/0x2d [igb]
 [] igb_request_irq+0x73/0x297 [igb]
 [] __igb_open+0xc8/0x223 [igb]
 [] igb_open+0x13/0x15 [igb]
 [] __dev_open+0xbf/0x120
 [] __dev_change_flags+0xa1/0x180
 [] dev_change_flags+0x28/0x70
 [] devinet_ioctl+0x5b7/0x620
 [] inet_ioctl+0x88/0xa0
 [] sock_do_ioctl+0x30/0x70
 [] sock_ioctl+0x72/0x270
 [] do_vfs_ioctl+0x8c/0x340
 [] sys_ioctl+0xa1/0xb0
 [] system_call_fastpath+0x16/0x1b
Code: 48 89 df e8 1f 40 ed ff 4d 39 e6 49 8b 45 10 75 b6 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 7b 20 e8 3e 91 db ff eb ae <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
RIP  [] free_msi_irqs+0x124/0x130
 RSP 

Signed-off-by: Stefan Assmann 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Abdallah Chatila

r8169: avoid NAPI scheduling delay.

2013-01-21T19:45:24+00:00

commit 7dbb491878a2c51d372a8890fa45a8ff80358af1 upstream.

While reworking the r8169 driver a few months ago to perform the
smallest amount of work in the irq handler, I took care of avoiding
any irq mask register operation in the slow work dedicated user
context thread. The slow work thread scheduled an extra round of NAPI
work which would ultimately set the irq mask register as required,
thus keeping such irq mask operations in the NAPI handler.
It would eventually race with the irq handler and delay NAPI execution
for - assuming no further irq - a whole ksoftirqd period. Mildly a
problem for rare link changes or corner case PCI events.

The race was always lost after the last bh disabling lock had been
removed from the work thread and people started wondering where those
pesky "NOHZ: local_softirq_pending 08" messages came from.

Actually the irq mask register _can_ be set up directly in the slow
work thread.

Signed-off-by: Francois Romieu 
Reported-by: Dave Jones 
Tested-by: Marc Dionne 
Cc: Thomas Gleixner 
Cc: Hayes Wang 
Signed-off-by: David S. Miller

ne2000: add the right platform device

2013-01-11T17:06:27+00:00

[ Upstream commit da9da01d9199b5bb15289d0859053c9aa3a34ac0 ]

Without this udev doesn't have a way to key the ne device to the platform
device.

Signed-off-by: Alan Cox 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnx2x: remove redundant warning log

2012-12-10T18:59:40+00:00

commit 4a25417c20fac00b3afd58ce27408f964d19e708 upstream.

fix bug where a register which was only meant to be read in 578xx/57712
devices causes a bogus error message to be logged when read from other
devices.

Signed-off-by: Ariel Elior 
Signed-off-by: Eilon Greenstein 
Signed-off-by: David S. Miller 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

ixgbe: add support for X540-AT1

2012-12-03T19:47:11+00:00

commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.

This patch adds device support for Ethernet Controller X540-AT1.

Signed-off-by: Josh Hay 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Abdallah Chatila 
Signed-off-by: Greg Kroah-Hartman

sky2: Fix for interrupt handler

2012-11-26T19:38:01+00:00

commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.

Re-enable interrupts if it is not our interrupt

Signed-off-by: Mirko Lindner 
Signed-off-by: David S. Miller 
Cc: Jonathan Nieder 
Signed-off-by: Greg Kroah-Hartman

r8169: allow multicast packets on sub-8168f chipset.

2012-11-26T19:37:48+00:00

commit 0481776b7a70f09acf7d9d97c288c3a8403fbfe4 upstream.

RTL_GIGA_MAC_VER_35 includes no multicast hardware filter.

Signed-off-by: Nathan Walp 
Suggested-by: Hayes Wang 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: Fix WoL on RTL8168d/8111d.

2012-11-26T19:37:47+00:00

commit b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd upstream.

This regression was spotted between Debian squeeze and Debian wheezy
kernels (respectively based on 2.6.32 and 3.2). More info about
Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
following thread: http://marc.info/?t=132079219400004

Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19;
more chipsets are likely affected.

Tested on top of a 3.2.23 kernel.

Reported-by: Florent Fourcot 
Tested-by: Florent Fourcot 
Hinted-by: Francois Romieu 
Signed-off-by: Cyril Brulebois 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: use unlimited DMA burst for TX

2012-11-26T19:37:47+00:00

commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.

The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
a box where this prevents the interface from using the gigabit line to its full
potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.

The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
(XID 0c900880). TSO is enabled.

I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
'7'=unlimited). This chart shows the results:
http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png

Interesting points:
 - With the current DMA burst limit (1024):
   - at the default MTU=1500 I get only 842 Mbit/s.
   - when going from small MTU, the performance rises monotonically with
     increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
     a sudden drop to 762 MBit/s from which the throughput rises monotonically
     again with further MTU increases.
 - With a smaller DMA burst limit (512):
   - there's a similar peak at MTU=1076 and another one at MTU=564.
 - With unlimited DMA burst:
   - at the default MTU=1500 I get nice 940 Mbit/s.
   - the throughput rises monotonically with increasing MTU with no strange
     peaks.

Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
limit plus 52. Why 52? Because:
  20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52

The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
the smaller burst limit, or if any other versions have similar requirements.

Signed-off-by: Michal Schmidt 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net/ethernet/nxp/lpc_eth.c: Call mdiobus_unregister before mdiobus_free

2012-11-17T21:16:18+00:00

[ Upstream commit 57c10b61c84bfed68b1b317d6f507a392724b9c4 ]

Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0

Calling mdiobus_free without calling mdiobus_unregister causes
BUG_ON(). This patch fixes the issue.

The semantic patch that found this issue(http://coccinelle.lip6.fr/):
// 
@@
expression E;
@@
  ... when != mdiobus_unregister(E);

+ mdiobus_unregister(E);
  mdiobus_free(E);
// 

Signed-off-by: Peter Senna Tschudin 
Tested-by: Roland Stigge 
Tested-by: Alexandre Pereira da Silva 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman