Re: [patch]: ide dma timeout retry in pio

[Jens Axboe <axboe@kernel.org>]

On Mon, May 28 2001, Andre Hedrick wrote:
> > > resorting to PIO would be such a shame, not only because it eats
> > > CPU so badly, but also because it has no checksum like UDMA...
> > 
> > Look at the patch -- we resort to pio for _one_ hunk. That's 8 sectors
> > tops, then back to dma. Hardly a big issue.
> 
> Unless we reissue the entire request from scratch you have no idea what if
> anything is on the platters.  Since one can generally only get control
> over the device with a soft reset, you have to assume that anything and
> everything about that request was lost at the device level and begin
> again.

Look at the patch, that's what it does. For ide dma, it's all or
nothing. So if it times out, no part of the request is ended
ide_dma_timeout_retry does the sanity re-setup of the request for good
measure, and it might be needed in the future when ide dma can do
partial requests (2.5, not now). The request _is_ reissued from scratch.

> <RANT>
> This is why it is so important to change to TFAM, because we carry a copy
> of the setup-seek operations with the request, and not unless we error out
> do we change that content.  Thus is a timeout fault not a error case we
> have all the info to re-issue or copy into a retry queue.  But as we all
> know the proper fix can not be even attempted until 2.5...
> </RANT>

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.

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

> means the request_struct needs fault counter.  If it is truly a DMA error

->errors, it's already there.

> because of re-seeks then the timeout value for that request must be
> expanded.

Yep

-- 
Jens Axboe