3c59x: recurring transmit errors

Chris Linstid cwl1408@rit.edu
Tue Jul 28 14:43:18 1998

What relevance does this have to this mailing list?

At 11:14 AM 7/28/98 +0200, Kevin Cameron wrote: 


FRIEND:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have you tried nfs
writes under linux ?

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the best case, it is 10% of
the performance

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of nfs writes under solaris or

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (i use freebsd because it
handles large jobs,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; much, much better than linux,
and handles nfs

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a million times better than
linux.&nbsp; however,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; linux is more popular, and may
win in the long

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; run.&nbsp; i tell
people:&nbsp; if you use linux instead

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of windoz-nt, consider
yourself very, very fortunate.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if you use freebsd instead,
consider yourself

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enlightened).&nbsp; watch out
for disk crashes under

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; linux - the extfs file system
is like the ufs

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filesystem running with the
-async switch - ie,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fsck equivalent under linux is
not guarnteed to be

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; able to recover from all power
crashes (bob&nbsp;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ran into this, and has now

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to freebsd).You might be
blaming the wrong thing.Kev.Ben Liblit wrote:

<excerpt>I am running Linux 2.0.35 with 3c59x driver version 0.99E on a

megabit network. 

    3c59x.c:v0.99E 5/12/98 Donald Becker

    eth0: 3Com 3c595 Vortex 100baseTX at 0xff80, 00:a0:24:c5:ef:f0, IRQ 7 

      Internal config register is 101001b, transceivers 0xe10a. 

      64K word-wide RAM 3:1 Rx:Tx split, autoselect/10baseT interface. 

    eth0: Overriding PCI latency timer (CFLT) setting of 64, new value is

    eth0: Initial media type 100baseTX. 

    eth0: vortex_open() InternalConfig 0141001b. 

    eth0: vortex_open() irq 7 media status 8802. 

    eth0: Media selection timer tick happened, 100baseTX. 

    eth0: Media 100baseTX has link beat, 8882. 

    eth0: Media selection timer finished, 100baseTX. 

Several times a day, I seem to lose all network connectivity through 

this interface.  This is an NFS-intensive environment, so NFS timeouts 

are generally the first symptom.  The driver reports transmit errors 

with one of three different status registers: 

    eth0: Transmit error, Tx status register 90. 

    eth0: Transmit error, Tx status register c0. 

    eth0: Transmit error, Tx status register 90. 

    eth0: Transmit error, Tx status register 90. 

    NFS server asterope.CS.Berkeley.EDU not responding, still trying. 

    NFS server asterope.CS.Berkeley.EDU not responding, still trying. 

    eth0: Transmit error, Tx status register d0. 

    NFS server asterope.CS.Berkeley.EDU OK. 

    NFS server asterope.CS.Berkeley.EDU OK. 

"ifconfig" records the following tally of problems: 

    TX packets:734220 errors:0 dropped:0 overruns:8 carrier:8 coll:872 

The network generally returns after about one to five minutes.  During 

that span, the CPU is pegged at 100% by a pair of "nfsiod" processes. 

A "traceroute" reports "host unreachable" for any address I might care 

to try. 

During these network outages, other machines on the same subnet 

continue to operate normally.  Also, I have never experienced similar 

outages when running NT on the same machine.  So at this point I am 

inclined to suspect the Linux 3c59x driver. 

Any ideas?

</excerpt>--  <<http://www.grfx.com>http://www.grfx.com