[tulip-bug] oddities with tulip.c (v0.92 4/17/2000) & compile problems

[Donald Becker]

On Mon, 27 Nov 2000, Keith Warno wrote:

> I've been using version 2.0 of the Linksys EtherFast 10/100 board along
> with the v0.92 tulip driver in Linux for many moons without a problem. 
> That is until last night.
> 
> I recently upgraded my home machine from a pIII 500 to a Thunderbird
> 1000.  The upgrade was done last Wednesday evening (*not* last night

The recent PIIIs are not too bad with power.  The Thunderbird is a real
power hog.  I suspect a heat problem.

> when the problems occured).  Everything in the new box, with the
> exception of the mainboard, CPU and RAM, is identical to the old setup
> which worked flawlessly.  The kernel is 2.2.17 and out of nowhere last
> night the network vanished.
> 
> I thought the culprit was my masq box but probing through syslog files
> on the downed machine I came across the following:
> 
> Nov 26 21:05:25 behemoth kernel: eth0: Transmit timed out, status
> ffffffff, CSR12 4081d0cc, resetting...

Bad... the 0xffffffff status means that the hardware isn't responding.  The
driver can't do anything about broken hardware.

> Unfortunately I did not have a copy of tulip-diag at the time of the
> downtime.  Output of tulip-diag -f -aa -ee at the time of this email,
....
> I couldn't get the network card back up without a reboot.  I tried
> removing the module and re-inserting it but this didn't work; I got a
> "device is busy" error.  :/

This is another indication of a hardware problem.  The driver completely
reconfigures the chip when the module is loaded, and resets the chip at each
open().

> On a different note, why doesn't the tulip driver compile with gcc
> v2.95.2 under Linux?  Neither tulip.c nor pci-scan.c (any recent version
> I could find) will build with this version of gcc; it generates a slew
> of errors, much too many to list here.  I've tried on two different
> linux boxes (SuSE 6.2 and SuSE 6.4).  Both the tulip.c and pci-scan.c,
> however, (seemingly) build find with gcc 2.91.66.

The driver worked with every generation of previous compile system, and it
doesn't work now.  I would say the burden of demonstrating correct behavior
is on the compile system, not the driver.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993