libata todo item: retry certain classes of errors
libata error handling is still of the "stupid simple" variety. While that makes it easy to verify, it also means that we don't always recover
from some situations.
Right now, libata simply returns an error back to the SCSI layer.
For DMA, PCI and SATA bus errors, we need to reset the hardware and retry the command.
It's a fairly important project, for anyone ambitious. Error handling must be improved before I implement queueing (and possibly hotplug).
Jeff
Quoted 5 lines · Jeff Garzik
libata error handling is still of the "stupid simple" variety. While that makes it easy to verify, it also means that we don't always recover
from some situations.Right now, libata simply returns an error back to the SCSI layer.
I did actually arrange that all the SCSI errors it faked caused the right retry behaviour at the SCSI level when I did that. Perhaps I should have commented that fact.
Quoted 2 lines
For DMA, PCI and SATA bus errors, we need to reset the hardware and retry the command.
And for PATA at least possibly also change mode and restore settings.
Alan
Quoted 11 lines · Alan Cox
Quoted 4 lines · Jeff Garzik
libata error handling is still of the "stupid simple" variety. While that makes it easy to verify, it also means that we don't always recover
from some situations.Right now, libata simply returns an error back to the SCSI layer.
I did actually arrange that all the SCSI errors it faked caused the right retry behaviour at the SCSI level when I did that. Perhaps I should have commented that fact.
Well the retry needs to e.g. include a bus reset prior to retrying.
Jeff
Quoted 6 lines · Jeff Garzik
Quoted 3 lines · Alan Cox
I did actually arrange that all the SCSI errors it faked caused the right retry behaviour at the SCSI level when I did that. Perhaps I should have commented that fact.
Well the retry needs to e.g. include a bus reset prior to retrying.
Thats possibly true for some situations. You might also want to avoid issuing resets as much as you can because they are a rather good source of "my drive
went away" error reports with the IDE layer (and they take forever).
Quoted 8 lines · Alan Cox
Quoted 6 lines · Jeff Garzik
Quoted 3 lines · Alan Cox
I did actually arrange that all the SCSI errors it faked caused the right retry behaviour at the SCSI level when I did that. Perhaps I should have commented that fact.
Quoted 7 lines
Quoted 1 line
Well the retry needs to e.g. include a bus reset prior to retrying.
Thats possibly true for some situations. You might also want to avoid issuing resets as much as you can because they are a rather good source of "my drive
went away" error reports with the IDE layer (and they take forever).
libata does a reset at the beginning of the probe...
Jeff
Quoted 3 lines · Jeff Garzik
Quoted 1 line
went away" error reports with the IDE layer (and they take forever).
libata does a reset at the beginning of the probe...
Thats fine but resets when the drive is error handling get "interesting"