Transmit timeout errors

[Scott Jangro]

I bought a small-format PC (all-in-one motherboard with an on-board ethernet
adapter) for use as my linux ipmasquerading firewall.

The on-board ethernet (eth0) is a Realtek 8139 for which I use the
rtl8139 module.  My linux is actually the Linux Router Project which is
based on Debian.  The kernel is version 2.0.36. I have a second NIC in this
machine (eth1) which is a different brand NIC which uses the ne module.

The configuration works great, however...

Occasionally, the realtek interface craps out and the kern.log fills with
this series of messages every minute or so, always the same numbers except
sometimes it says 'status 0d 2000' instead of 'status 0d 0000':

Apr 19 08:35:15 bugs kernel: eth0: Transmit timeout, status 0d 0000.
Apr 19 08:35:15 bugs kernel: eth0:  Tx descriptor 0 is 00002000. (queue
head)
Apr 19 08:35:15 bugs kernel: eth0:  Tx descriptor 1 is 00002000.
Apr 19 08:35:15 bugs kernel: eth0:  Tx descriptor 2 is 00002000.
Apr 19 08:35:15 bugs kernel: eth0:  Tx descriptor 3 is 00002000.
Apr 19 08:35:15 bugs kernel: eth0: MII status register is 782d.

I've been using this system for about 5 days.  It has stopped working twice
in that span with this problem.  I'm pretty confident that there are
no hardware conflicts.  After this happens, the eth0 iterface is pretty
much dead until I reboot.

Is this a known problem with the realtek chipset?  I see the notes on
Donald's website stating:

"If you encounter Rx overflow errors and transmit timeouts you likely have
the card in a non-bus-master slot. Other possible problems are older PCI
implementations, especially i486-class motherboards, that have bugs when
using long PCI burst transfers."

However, this is a relatively new motherboard and the 8139 is built-in
(Unicorn Computer, ENDAT-586HL (socket7 baby-AT), though I cannot vouch for
its design quality:
http://www.unicorn-computer.com.tw/product/586HL.html

I don't know how recently the rtl8139.o module that I'm using was built (I
downloaded the binary from the LRP site).  I see that the source has been
modified within the past few weeks so if you think this may be resolved in
the current version of the driver, that will encourage me enough to get a
development setup configured so I can build it myself.

thanks for your help,

 --Scott


 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.