[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH][2.5] 3c509 increase udelay in *read_eeprom
From:       Jeff Garzik <jgarzik () pobox ! com>
Date:       2002-10-28 19:09:35
[Download RAW message or body]

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/
[prev in list] [next in list] [prev in thread] [next in thread]