Re: Linux 2.5.67-ac2: ide reset issue

rain.wang (rain.wang@mic.com.tw)
Sat, 19 Apr 2003 15:38:17 +0800


Alan Cox wrote:

> > I don't know if there's enough reason to change reset semantics
> > now to wait for completion, so that the next call be free of race.
> > and I once had a simpler fix to let it delay another 50ms, that works
> > on my box but seems not a thorough one. does it help?
>
> BWGROUP(drive)->busy should never reach zero until the reset is
> done. The 50mS miught be enough that this occurs, as might waiting
> for HWGROUP(drive)->busy hitting 0. I don't yet understand why it
> matters, and to fix it properly I have to figure that out.
>
> If you need reliable reset for something like a test harness, or
> IDE drive tester its a usable workaround, but I need to fix it
> properly (eventually)
>

I agree. I found the reason seems some strange there. reset call set
a 50ms's wait handler and return to user at once, when succeed in
the first poll and handler return, there's always about another 50ms
needed to cleanup the path(I once tested values lager and smaller
than 50ms and found about 48ms needed at least on my box). so
the following call would race it if there's no such a delay, although
there's actually few chances to do continuous reset call, I thought.

> > + /* wait for another 50ms */
> > + mdelay(50);
>
> In your test set is HWGROUP(drive)->busy always zero after the
> mdelay ?

I think it is.

-
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/