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.
> 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...
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
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/