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: 
>>>>
<excerpt>HERE IS A COMMENT FROM A
FRIEND:        have you tried nfs
writes under linux ?
        in the best case, it is 10% of
the performance
        of nfs writes under solaris or
freebsd.
        (i use freebsd because it
handles large jobs,
        much, much better than linux,
and handles nfs
        a million times better than
linux.  however,
        linux is more popular, and may
win in the long
        run.  i tell
people:  if you use linux instead
        of windoz-nt, consider
yourself very, very fortunate.
        if you use freebsd instead,
consider yourself
        enlightened).  watch out
for disk crashes under
        linux - the extfs file system
is like the ufs
        filesystem running with the
-async switch - ie,
        fsck equivalent under linux is
not guarnteed to be
        able to recover from all power
crashes (bob 
        ran into this, and has now
switched
        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
100 
megabit network. 
    3c59x.c:v0.99E 5/12/98 Donald Becker
<<http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html>http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html 
    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
248. 
    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
<<mailto:dkc@grfx.com>mailto:dkc@grfx.com  
</excerpt><<<<<<<<