Re: eepro100 1.0.3 patch

Donald Becker (becker@cesdis1.gsfc.nasa.gov)
Fri, 16 Oct 1998 01:01:21 -0400 (EDT)


On Thu, 15 Oct 1998, Serguei Koubouchine wrote:

> > > Please find the patch against 1.0.3 enclosed. I did never write ethernet

The patch adds mdio_read() at the end of open() -- this shouldn't have any
effect -- and doesn't on my system.
But it's inexpensive and I'll it to my next driver release.

> > > Telesyn inclusive). It does not have any problems with gated-3.5.10 and
> > > multicasting so far (kernel 2.1.125-ac2).
> >
> > I tried this and got "Transmit timed out" within 2 minutes with
> > Netatalk installed. Back to multicast_filter_limit=3... Kernel version
> > 2.0.35.

Use
http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c

This fixes a race condition triggered by rapid additions or deletions to the
multicast filter list.
I'm coming up with a better fix that adaptively puts the chip in
Rx-all-multicast mode when manipulating the list, and only goes through the
slow process of installing the multicast filter when the list is stable.

Installing the multicast list turns off both the transmitter and receiver!
It's slow with long lists because the chip computes the hash filter table
from the multicast addresses themselves, rather than taking a precomputed
table as most other chips do.

> Dunno about 2.0.xx ... I don't have it somewhere in reach, we do use either
> 2.0.34 on 6 month+ up servers where the default driver does work for us,
> multicasting included, or 2.1.1-almost-the-latest on lighter loaded servers
> and workstations.

v1.03 is stable in normal operation. The two operations that will kill it
are:
rapidly changing the multicast list (complex fix: just get v1.04).
running out of memory (fix: move the rx_work_limit check to the top of the
loop)

> Anyway, this little patch does nothing to multicasting and another precious
> inner parts of the driver. It does solve the problem of some eepro100 cards
> with i82557 chip (the a.m. AT-2560TX among the others) turning their LEDs
> off right after being ifconfiged, i.e. those which could be cured by running
> mii-diag right after ifconfig.

This problem is chip version specific.

Donald Becker becker@cesdis.gsfc.nasa.gov
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-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/