Messages in this thread | | | Date | Tue, 29 May 2001 00:26:00 +0200 | From | Jens Axboe <> | Subject | Re: [patch]: ide dma timeout retry in pio |
| |
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
- 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/
| |