On Tue, 29 May 2001, Jens Axboe wrote:
> This is bull shit. If IDE didn't muck around with the request so much in
> the first place, the info could always be trusted. Even so, we have the
> hard_* numbers to go by. So this argument does not hold.
Maybe if you looked at the new code model as a whole you would see that
the request-forking is gone. The object is to preserve a copy of the io
instructions out to the registers to not have to repeat the do_request
call unless it is a do or die thing. Also it is good to carry a copy of
the local request even if it is never used. Also are you resetting the
pointer (back to the geginning) on rq->buffer on the retry?
You first flush the DMA engine and issue a device soft reset not using the
current drive reset, is presevers the hwgroup->busy state and allows the
request to be retried without reinserting.
> > As I recall, there is a way to reinsert the faulted request, but that
>
> Again, look at the patch. The request is never off the list, so there is
> never a reason to reinsert. hwgroup->busy is cleared (and, again for
> good measure, hwgroup->rq), so ide_do_request/start_request will get the
> same request that we just handled.
I will have to poke in a few flags to verify this but if you say so.
> > means the request_struct needs fault counter. If it is truly a DMA error
>
> ->errors, it's already there.
Wrong location to poke and by that time it requires a full retry.
The new code would have had the task structs filled with the error.
> > because of re-seeks then the timeout value for that request must be
> > expanded.
>
> Yep
In some cases yes, but it would be better if I had a standard counter that
meant something. Also changing the jiffie counter in ide_delay_50ms to a
mdelay may have done more harm than good.
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
