> >> Server info at http://www-jcr.lmh.ox.ac.uk/ferret.html, but the
> >> big problem is still the 3c59x driver. We went back to 0.46C
> >> after similar problems with 0.9, or whatever's in p11b.
>
> Alan> I dropped back to the old driver in 2.0.34pre12/13 too. For
What! That's not a good idea!
> Alan> the people with the newer cards it appears the latest driver
> Alan> is wonderfully fast, stable and the very latest is SMP safe
> Alan> but the old card users keep reporting fails.
I don't think there there is any magic in 0.46C that would make it better,
and it *does not work* with the current-production cards!
I have an additional error recovery path in my latest testing version.
http://cesdis.gsfc.nasa.gov/linux/drivers/test/3c59x.c
This was needed on a 486 PCI box that has known PCI bugs.
I'll look at the locking again.
> While we're on the topic:
>
> I've been having a few problems on an older 3c590 card with the
> drivers in the late 2.1.xx series. I found I had to increase a
> 'timeout' value in order to get the driver to read the EEPROM
> correctly (one-line patch is included). Does anybody know why this is
> happening?
The current driver has the loop count at 10.
> I'm fairly sure it is not overoptimization of the 'udelay' function
> (I normally compile using egcs-1.0.2, but I've tried stock kernels
> with gcc-2.7.3.3).
I'm fairly certain that this *is* a udelay() bug. The EEPROM read typically
takes about 120usec. on my board, and the 162usec number comes from the
hardware documentation. Several people that reported this as a problem
noted that it "broke" with a kernel update.
> /* Pause for at least 162 us. for the read to take place. */
> - for (timer = 4; timer >= 0; timer--) {
> + for (timer = 256; timer >= 0; timer--) {
> udelay(162);
> if ((inw(ioaddr + Wn0EepromCmd) & 0x8000) == 0)
> break;
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/pub/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