Messages in this thread | | | Date | Sat, 19 Apr 2003 15:38:17 +0800 | From | "rain.wang" <> | Subject | Re: Linux 2.5.67-ac2: ide reset issue |
| |
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/
| |