Re: [PATCH][2.5] 3c509 increase udelay in *read_eeprom

Jeff Garzik (jgarzik@pobox.com)
Mon, 28 Oct 2002 14:09:35 -0500


Zwane Mwaikambo wrote:

>Hi Jeff,
>This is David's patch, find his reasoning and patch below.
>
>"... I had to set the udelay() call parameters to 2000 in read_eeprom()
>and 4000 in id_read_eeprom() to get the system to boot reliably with 2
>3c509's in it. If I didn't set these values high enough, I got an oops
>about 1/3 of the time when I booted....somehow (I'm guessing) it just
>took the cards longer to initialize/respond when there were two of them
>on the bus.
>
>I know the possibility of this (and the fix, setting the values higher) is
>mentioned in Becker's 3c509 instructions, but I wanted to relay my
>experience to you as well. Since AFAIK these subroutines are only called
>at initialization time (we don't need to read the EEPROM after init), what
>would be the harm of setting these values higher - at least 1000 for both,
>say - in the standard driver? Certainly a millisecond or two means nothing
>at boot time, and if it prevents even a few machines from mysteriously
>oopsing when they're started, it's a win overall ..."
>
>

lol... big udelays are almost always wrong.

First, long delays lock out everybody, thus you should do operations
that require long waits via a timer or schedule_timeout() in process
context.
Second, udelay of 1000 or greater is a bug, use mdelay() instead.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/