linux-toradex.git/drivers/net/r8169.c, branch v2.6.27.49 Linux kernel for Apalis and Colibri modules r8169: Fix receive buffer length when MTU is between 1515 and 1536 2010-04-01T22:52:18+00:00 Raimonds Cicans ray@apollo.lv 2009-11-13T10:52:19+00:00 e2db86fdddfbf179ebc8e717b50770cf7acf78b6 commit 8812304cf1110ae16b0778680f6022216cf4716a upstream. In r8169 driver MTU is used to calculate receive buffer size. Receive buffer size is used to configure hardware incoming packet filter. For jumbo frames: Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4 (vlan header) + 4 (ethernet checksum) = MTU + 22 Bug: driver for all MTU up to 1536 use receive buffer size 1536 As you can see from formula, this mean all IP packets > 1536 - 22 (for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware filter. Example: host_good> ifconfig eth0 mtu 1536 host_r8169> ifconfig eth0 mtu 1536 host_good> ping host_r8169 Ok host_good> ping -s 1500 host_r8169 Fail host_good> ifconfig eth0 mtu 7000 host_r8169> ifconfig eth0 mtu 7000 host_good> ping -s 1500 host_r8169 Ok Bonus: got rid of magic number 8 Signed-off-by: Raimonds Cicans <ray@apollo.lv> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8812304cf1110ae16b0778680f6022216cf4716a upstream.

In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.

For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22

Bug:
driver for all MTU up to 1536 use receive buffer size 1536

As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.

Example:

host_good>  ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good>  ping host_r8169
Ok
host_good>  ping -s 1500 host_r8169
Fail
host_good>  ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good>  ping -s 1500 host_r8169
Ok

Bonus: got rid of magic number 8

Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: avoid losing MSI interrupts 2009-07-30T23:06:14+00:00 David Dillow dave@thedillows.org 2009-07-22T16:17:06+00:00 2fe2c6bb0303064bde3b8ca0fd90c4367868486e [ Upstream commit f11a377b3f4e897d11f0e8d1fc688667e2f19708 ] The 8169 chip only generates MSI interrupts when all enabled event sources are quiescent and one or more sources transition to active. If not all of the active events are acknowledged, or a new event becomes active while the existing ones are cleared in the handler, we will not see a new interrupt. The current interrupt handler masks off the Rx and Tx events once the NAPI handler has been scheduled, which opens a race window in which we can get another Rx or Tx event and never ACK'ing it, stopping all activity until the link is reset (ifconfig down/up). Fix this by always ACK'ing all event sources, and loop in the handler until we have all sources quiescent. Signed-off-by: David Dillow <dave@thedillows.org> Tested-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit f11a377b3f4e897d11f0e8d1fc688667e2f19708 ]

The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.

The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.

Signed-off-by: David Dillow <dave@thedillows.org>
Tested-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: fix crash when large packets are received 2009-07-02T23:31:36+00:00 Eric Dumazet eric.dumazet@gmail.com 2009-06-09T11:01:02+00:00 d6e4c46321f5e4a5060e873b1ed5e4d0c25b774e commit fdd7b4c3302c93f6833e338903ea77245eb510b4 upstream. Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit fdd7b4c3302c93f6833e338903ea77245eb510b4 upstream.

Michael Tokarev reported receiving a large packet could crash
a machine with RTL8169 NIC.
( original thread at http://lkml.org/lkml/2009/6/8/192 )

Problem is this driver tells that NIC frames up to 16383 bytes
can be received but provides skb to rx ring allocated with
smaller sizes (1536 bytes in case standard 1500 bytes MTU is used)

When a frame larger than what was allocated by driver is received,
dma transfert can occurs past the end of buffer and corrupt
kernel memory.

Fix is to tell to NIC what is the maximum size a frame can be.

This bug is very old, (before git introduction, linux-2.6.10), and
should be backported to stable versions.

Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: reset IntrStatus after chip reset 2009-05-02T17:24:44+00:00 Francois Romieu romieu@fr.zoreil.com 2009-04-16T21:35:17+00:00 5e7675e9c311b657bd75bcf7038d3d73e9b8e9e8 Upstream as d78ad8cbfe73ad568de38814a75e9c92ad0a907c (post 2.6.29). Original comment (Karsten): On a MSI MS-6702E mainboard, when in rtl8169_init_one() for the first time after BIOS has run, IntrStatus reads 5 after chip has been reset. IntrStatus should equal 0 there, so patch changes IntrStatus reset to happen after chip reset instead of before. Remark (Francois): Assuming that the loglevel of the driver is increased above NETIF_MSG_INTR, the bug reveals itself with a typical "interrupt 0025 in poll" message at startup. In retrospect, the message should had been read as an hint of an unexpected hardware state several months ago :o( Fixes (at least part of) https://bugzilla.redhat.com/show_bug.cgi?id=460747 Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Josep <josep.puigdemont@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as d78ad8cbfe73ad568de38814a75e9c92ad0a907c (post 2.6.29).

Original comment (Karsten):
On a MSI MS-6702E mainboard, when in rtl8169_init_one() for the first time
after BIOS has run, IntrStatus reads 5 after chip has been reset.
IntrStatus should equal 0 there, so patch changes IntrStatus reset to happen
after chip reset instead of before.

Remark (Francois):
Assuming that the loglevel of the driver is increased above NETIF_MSG_INTR,
the bug reveals itself with a typical "interrupt 0025 in poll" message
at startup. In retrospect, the message should had been read as an hint of
an unexpected hardware state several months ago :o(

Fixes (at least part of) https://bugzilla.redhat.com/show_bug.cgi?id=460747

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Josep <josep.puigdemont@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: use hardware auto-padding. 2009-05-02T17:24:43+00:00 Francois Romieu romieu@fr.zoreil.com 2009-04-16T21:34:24+00:00 7627613b64210b454164a8dbe6b4681da9ed1bb7 Upstream as 97d477a914b146e7e6722ded21afa79886ae8ccd (post 2.6.28). It shortens the code and fixes the current pci_unmap leak with padded skb reported by Dave Jones. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as 97d477a914b146e7e6722ded21afa79886ae8ccd (post 2.6.28).

It shortens the code and fixes the current pci_unmap leak with
padded skb reported by Dave Jones.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: Don't update statistics counters when interface is down 2009-05-02T17:24:40+00:00 Francois Romieu romieu@fr.zoreil.com 2009-04-16T21:33:00+00:00 67b9b52d81ad636ae454e474ed52eb145d8284b5 Upstream as 355423d0849f4506bc71ab2738d38cb74429aaef (post 2.6.28). Some Realtek chips (RTL8169sb/8110sb in my case) are unable to retrieve ethtool statistics when the interface is down. The process stays in endless loop in rtl8169_get_ethtool_stats. This is because these chips need to have receiver enabled (CmdRxEnb bit in ChipCmd register) that is cleared when the interface is going down. It's better to update statistics only when the interface is up and otherwise return copy of statistics grabbed when the interface was up (in rtl8169_close). It is interesting that PCI-E NICs (like 8168b/8111b...) are not affected. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as 355423d0849f4506bc71ab2738d38cb74429aaef (post 2.6.28).

Some Realtek chips (RTL8169sb/8110sb in my case) are unable to retrieve
ethtool statistics when the interface is down. The process stays in
endless loop in rtl8169_get_ethtool_stats. This is because these chips
need to have receiver enabled (CmdRxEnb bit in ChipCmd register) that is
cleared when the interface is going down. It's better to update statistics
only when the interface is up and otherwise return copy of statistics
grabbed when the interface was up (in rtl8169_close).

It is interesting that PCI-E NICs (like 8168b/8111b...) are not affected.

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: wake up the PHY of the 8168 2008-11-13T17:55:59+00:00 Francois Romieu romieu@fr.zoreil.com 2008-11-08T11:06:09+00:00 366c22cf9d9dd7cdcbb7c14bed44e91018672cda Upstream as a2de6b89b74b28052e293fdb39975a5a03c432e0 This is typically needed when some other OS puts the PHY to sleep due to the disabling of WOL options in the BIOS of the system. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Chiaki Ishikawa <chiaki.ishikawa@ubin.jp> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Cc: RyanKao <ryankao@realtek.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as a2de6b89b74b28052e293fdb39975a5a03c432e0

This is typically needed when some other OS puts the PHY
to sleep due to the disabling of WOL options in the BIOS
of the system.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Chiaki Ishikawa <chiaki.ishikawa@ubin.jp>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Cc: RyanKao <ryankao@realtek.com.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: fix RxMissed register access 2008-11-13T17:55:59+00:00 Francois Romieu romieu@fr.zoreil.com 2008-11-08T11:04:42+00:00 6269b8494da80250422ed8ce4e6ee7126c0010aa Upstream as 523a609496dbc3897e530db2a2f27650d125ea00 - the register is defined for the 8169 chipset only and there is no 8169 beyond RTL_GIGA_MAC_VER_06. - only the lower 3 bytes of the register are valid Fixes: 1. http://bugzilla.kernel.org/show_bug.cgi?id=10180 2. http://bugzilla.kernel.org/show_bug.cgi?id=11062 (bits of) Tested by Hermann Gausterer and Adam Huffman. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as 523a609496dbc3897e530db2a2f27650d125ea00

- the register is defined for the 8169 chipset only and there is
  no 8169 beyond RTL_GIGA_MAC_VER_06.
- only the lower 3 bytes of the register are valid

Fixes:
1. http://bugzilla.kernel.org/show_bug.cgi?id=10180
2. http://bugzilla.kernel.org/show_bug.cgi?id=11062 (bits of)

Tested by Hermann Gausterer and Adam Huffman.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: get ethtool settings through the generic mii helper 2008-11-13T17:55:59+00:00 Francois Romieu romieu@fr.zoreil.com 2008-11-08T11:03:09+00:00 38d501ca6eb1f05d238bef785e51ca71dbfe0115 Upstream as ccdffb9a88b2907b159538d7bfd6256621db4f84 (post 2.6.27). It avoids to report unsupported link capabilities with the fast-ethernet only 8101/8102. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Martin Capitanio <martin@capitanio.org> Fixed-by: Ivan Vecera <ivecera@redhat.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream as ccdffb9a88b2907b159538d7bfd6256621db4f84 (post 2.6.27).

It avoids to report unsupported link capabilities with
the fast-ethernet only 8101/8102.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Martin Capitanio <martin@capitanio.org>
Fixed-by: Ivan Vecera <ivecera@redhat.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: balance pci_map / pci_unmap pair 2008-08-27T09:16:24+00:00 Francois Romieu romieu@fr.zoreil.com 2008-08-26T19:56:06+00:00 a866bbf6aacf95f849810079442a20be118ce905 The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Alistair John Strachan <alistair@devzero.co.uk> Tested-by: Timothy J Fontaine <tjfontaine@atxconsulting.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
The leak hurts with swiotlb and jumbo frames.

Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468.

Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Alistair John Strachan <alistair@devzero.co.uk>
Tested-by: Timothy J Fontaine <tjfontaine@atxconsulting.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>