...
> > You can try to compile in the de4x5.c driver, and hardwire it to
> > 100Mbit/s. Have a look in the de4x5.c source code -- one has to activate
> > a certain define with certain values; hereafter the card should always
> > come up in 100Mbit/s mode.
>
> That workaround (hardwire the de4x5 driver to 100MBit) has worked well in
> the past. Also meeting with some success is using Donald Becker's latest
> tulip driver (0.89H?) and providing a media type argument on the boot
> command line, to perform the "hardwiring" at the last minute. Check his
> website for details (http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html).
The current tulip.c driver at 2.1.124/125 kernel is about a year old
(eh, really??) -- 10/19/97 wow.. but it nevertheless works fine at my
Miata (PWS 433a) against a cisco Catalyst 2924 (if I remember it right).
However against BayNet T350 10/100 switch it had problems at getting
speed negotiated to 100BaseT(fdx). Or rather, switch considered the speed
to be 10Mbps, while my machine considered it to be 100Mbps, and then *both*
switched to other speed at about the same time. Sigh...
Hardwiring the speed helped, of course.
> The builtin 21143 on the MIATA only seems to be a problem at 100Mbit, which,
> unfortunately, is becoming more widespread. The biggest problem is that
> neither driver writer has had decent access to a MIATA... :-\
Yeah, oddly the Tulip driver at 2.0.35 is from 4/7/98. (version 0.88)
The version of the Tulip driver at 2.1.124 contains various other
bugfixes, most important of which (I think) is SKB allocation out-of-memory
handling code, which Donald has not yet believed to be necessary for those
drivers which have rx_skbuff[] rings. :-(
Speaking of which, a quick browse shows me that:
tulip.c at 2.0.35 has this rx_skbuff[] ring problem.
3c59x.c (up to and including version 0.99G!) driver does blow up if that
ring can not be refilled successfully...
eepro100.c's code (at 2.1.124, v0.36) is rather unclear at what it does,
but it looks likely to be able to survive the situation.
de4x5.c (v0.542) driver will always alloc a new skb at an Alpha, and
then copy the data there. If the alloc fails, it is skipped. (No kernel
crash from that...) (But this isn't Donald's rx_skbuff[] beasts either..)
> --Jay++
> Jay A Estabrook Alpha Motherboards - LINUX Project
> Compaq Computer Corporation (508) 841-3241 or (DTN) 237-3241
> 334 South Street, Shrewsbury, MA 01545 [EMAIL PROTECTED]
/Matti Aarnio <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
