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.