> Hello all,
>
> Two days ago we got our first AMI Goliath 4PPro (Orion chipset, 128 MB mem).
> Because of our 'interesting' experiences with the 3c905, we ordered it with
> 2 Kingston KNE100TX Fast Ethernet cards, based on the DEC 21140-AE chip. The
> cards are connected to a Bay Fast Ethernet switch, port set for 100Mbps
> full duplex, flow control disabled.
>
> Trouble is, none of the 2.1 kernels I tried will work with this setup. The
> only config that *does* work is the 2.0.30 that comes with RH 4.2, with the
> de4x5 driver.
>
> configurations that do *not* work:
> - 2.0.30 with tulip driver
> - 2.1.35 or 2.1.38 or 2.1.48
> with de4x5 v0.5, de4x5 v0.52, de4x5 v0.442, tulip v0.72
One fairly minor suggestion: Get the latest tulip development drivers
(0.76 and/or 0.77) from
http://cesdis.gsfc.nasa.gov/linux/drivers/tulip-devel.html
and compile it as a module, not into the kernel. I'd recommend
getting the "tulip-probe" diagnostic tool from this same site and
reading the various docs on tricky configurations.
You should be able to specify options and possibly the irq on the
insmod line. In this way it may be possible to differentiate between
the two cards and force one to be eth0 and the other eth1. In your
boot messages below, it almost looks like it is trying to load both
cards as eth0 and this may be bollixing up the load.
I use KNE-100's here (under 2.0.30) on P6DNF's, and I've also observed
a fairly rare but nasty initialization bug. In some cases the cards
are not properly initialized by the initial insmod tulip. One can
ifconfig the device, but if one probes the card all the registers are
ff's, in particular the last byte of csr5. HOWEVER, if one ifconfig's
the interface down, rmmod the module, insmod the module, and ifconfig
a second time, the interface comes up perfectly and works like a charm
thereafter. This may be fixed in 0.77 -- I think that somebody posted
a fix to a minor bug that caused the cards to lock up when their
packet counts reached the maximum value, and those ff's make me think
that the cards might have been coming up in the max'd out state.
Now, I don't use two tulips but I have run a tulip and 3c905 (both on
the PCI bus at different interrupts) at once. And yes, you are wise
to go with two tulips (I think). Even running 3c59x.c 0.42n (the
absolute latest 3c905 driver) I get lockups in almost no time when I
hammer the card receiving. On the good side though, they've finally
got the transmission speed up into the 93 Mbps range -- a bit slower
than the tulips but quite acceptable.
Good luck,
rgb
P.S. -- you might cross-post this to linux-tulip. It may not be an
SMP problem per se...
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu