On Fri, 28 May 1999, Alan Cox wrote:
> To: Jason Gunthorpe <[EMAIL PROTECTED]>
> > Well hopefully VA will hear about this and stop shipping these cards with
> > their machines since they clearly do not work 100%. We will swap it out, I
> > have no desire to work with defective hardware/drivers at a distance.
>
> Try the current eepro100 driver not the one in the kernel. See if that
> helps
The eepro100.c driver v1.08 of 5/3/99 at
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
has the following changes:
PowerPC support (and, presumably, Sparc)
Uses atomic operations to clear the suspend bit of previous command when
adding to a command list. (This nominally shouldn't be needed, but...)
Dynamic control of multicast list changes. Changing the multicast filter
on this chip is painful. It stops reception, and perhaps transmitting,
during the change. The updated driver now doesn't attempt to queue a new
multicast filter list of more than three entries if the old list hasn't
been processed. Instead it switches to Rx-all-multicast mode and waits
for the next driver-watchdog timer tick to actually load the multicast
filter. (Given the problems with changing the filter list, I may have to
make this more clever e.g. if any change has happened in the last
filter_entries*jiffies, just leave the chip in Rx-all-multicast mode.)
If this version doesn't fix the Tx timeout problem (this message means that
the chip thinks its running, but hasn't accomplished anything), I'll have to
write the code to do a full reset inside the watchdog timer.
Donald Becker [EMAIL PROTECTED]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
