libata todo item: retry certain classes of errors

libata todo item: retry certain classes of errors

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

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

Re: libata todo item: retry certain classes of errors

[Alan Cox]

On Gwe, 2005-01-07 at 04:33, Jeff Garzik wrote:
> 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.

> 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

Re: libata todo item: retry certain classes of errors

[Jeff Garzik]

Alan Cox wrote:
> On Gwe, 2005-01-07 at 04:33, Jeff Garzik wrote:
> 
>>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

Re: libata todo item: retry certain classes of errors

[Alan Cox]

On Mer, 2005-02-02 at 01:50, Jeff Garzik wrote:
> Alan Cox wrote:
> > 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).

Re: libata todo item: retry certain classes of errors

[Alan Cox]

On Iau, 2005-02-03 at 17:24, Jeff Garzik wrote:
> > 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"

Re: libata todo item: retry certain classes of errors

[Jeff Garzik]

Alan Cox wrote:
> On Mer, 2005-02-02 at 01:50, Jeff Garzik wrote:
> 
>>Alan Cox wrote:
>>
>>>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).

libata does a reset at the beginning of the probe...

	Jeff