rtl8139 interface hangs using rtl8139 on Geode systems

"R. Steve McKown" <[email protected]> Thu, 27 Mar 2003 09:56:04 -0700
Newsgroups gmane.linux.drivers.realtek.devel
Organization Titanium Mirror, Inc
Message-ID <[email protected]>
Synopsis:

A network interface managed by the rtl8139 driver will stop responding, 
usually when relatively large amounts of traffic are present.  Occasionally, 
the failure will be associated with the output of log messages like the 
following:

eth1: Abnormal interrupt, status 00008
eth1: Transmit timeout, status 0d 0000 media 18

Once the interface becomes unresponsive, one sees arp who-has messages for its 
ip (and unrelated broadcast traffic) only (tcpdump -n -i eth1).  The 
interface never sends an arp reply to any request received.  When this 
occurs, all entries in the arp cache for neighbors reachable by the problem 
interface are eventually marked as having an incomplete line, presumably as 
those entries time out.  Or, one can delete those entries and see that no 
traffic will restore them.

The only way I've been able to resolve this problem is to down and up the 
interface.

To date, I have not yet been able to duplicate this problem when using the 
8139too driver.

I can reproduce the problem on two different hardware designs.  Both designs 
use the National Semiconductor Geode processors.  We've seen it under the 
Geode GXLV-200, Geode GXLV-233, and Geode GX1-300 processors (the first two 
on one hardware platform, the last on the second hardware platform).  The 
second hardware platform can also accept a Transmeta-based CPU (TM5400-500) 
module, and this system running the rtl8139 driver has not to date exhibited 
the symptoms.

There's some anectodal evidence to suggest that other traffic in the collision 
domain to which the interface is connected may exacerbate the frequency of 
this problem.

To replicate:

Set up hostA with 2 rtl8139 interfaces, connecting two networks.  Have hostB 
connected via hostA's eth0 interface and hostC connected via hostA's eth1 
interface.  Now, generate a large transfer from hostC to hostB, using hostA 
as a router.  The transfer should be large; I am using a 100MB test file.  In 
my tests, I've used scp.  It may take more than one transfer attempt to 
trigger the problem.

---- Systems information ----

HostA: eth0=172.16.0.133 eth1=10.9.0.1
HostB: 172.16.0.10
HostC: 10.9.0.10

hostA's kernel: 2.4.16 with patches
    rtl8139 driver v1.18 6/5/2002
    8139too driver v0.9.22

HostA's interface configuration:
[root@router0 /root]# ip addr list
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/24 brd 127.0.0.255 scope host lo
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: tunl0@NONE: <NOARP> mtu 1480 qdisc noop
    link/ipip 0.0.0.0 brd 0.0.0.0
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop
    link/gre 0.0.0.0 brd 0.0.0.0
13: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:d0:c9:20:87:31 brd ff:ff:ff:ff:ff:ff
    inet 10.9.0.1/24 brd 10.9.0.255 scope global eth0
14: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:d0:c9:20:87:30 brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.133/24 brd 172.16.0.255 scope global eth1

Network info:
HostA's eth0 is connected to a 10Mbps half-duplex (only) hub, connecting via 
two downstream 10/100 switches to hostB.  hostC and HostA's eth1 are 
connected to another 10Mbps half-duplex hub.  Two other machines are also 
connected, that generate low levels of network traffic.

hostA's lspci output (for the GXLV-based hardware platform)
[root@router0 /root]# lspci
00:00.0 Host bridge: Cyrix Corporation PCI Master
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua]
00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
00:13.0 USB Controller: Compaq Computer Corporation: Unknown device a0f8 (rev 
06)

hostA's lspci output (for the GX1-based hardware platform)
[root@tm0 /root]# lspci
00:00.0 Host bridge: Cyrix Corporation PCI Master
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
00:13.0 USB Controller: Compaq Computer Corporation: Unknown device a0f8 (rev 
06)

hostA's arp cache after the problem has surfaced and time for the entries to 
expire has passed:
[root@router0 /root]# arp -n
Address                 HWtype  HWaddress           Flags Mask           Iface
172.16.0.1              ether   00:D0:C9:48:49:75   C                     eth1
10.9.0.10                       (incomplete)                              eth0
172.16.0.10             ether   00:E0:7D:CA:AE:0B   C                     eth1

I'd be glad to provide any other information that might be helpful.

All the best,
Steve McKown
Titanium Mirror, Inc.