Re: [RFC] libata new EH document

Tejun Heo
2005-09-01T01:17:15Z

Luben Tuikov wrote:
> On 08/30/05 06:26, Tejun Heo wrote:
>
>>Albert Lee wrote:
>>
>>
>>>>4. Corresponding scmd's result code is set to
>>>> SAM_STAT_CHECK_CONDITION and qc->scsidone() callback is called
>>>> directly. As we haven't filled sense data,
>>>> scsi_determine_disposition() will return FAILED and SCSI EH will
>>>> be scheduled. Note that as we directly call qc->scsidone(), qc is
>>>> left intact.
>>>>
>>>>
>>>
>>>Could we get the sense data before calling qc->scsidone()? (Using the
>>>proposed separate
>>>EH qc can keep the original qc intact.)
>>>
>>>The issue:
>>>When a DVD drive returns MEDIUM_ERROR in the sense data, libata doesn't
>>>retry the command.
>>>
>>>For libata, when scsi_softirq() calls scsi_decide_disposition() and
>>>scsi_check_sense() to determine
>>>how to handle the result, scsi_check_sense() always returns "fail" since
>>>the sense data is not there
>>>yet. The sense data is requested later in the libata error handler. But
>>>the command has already been
>>>considered as an "error".
>>>
>>>By having the sense data ready before calling qc->scsidone(), we can
>>>make the
>>>NEEDS_RETRY work in scsi_softirq(). So, for things like MEDIUM_ERROR,
>>>the device has
>>>a chance to retry/recover the error. This seems to be important for
>>>devices with built-in
>>>defect management system.
>>
>>
>> There are two ways a scmd can leave EH - retry by scsi_queue_insert()
>>and finish by scsi_finish_cmd(). I think the problem you described can
>>be easily solved by choosing the former method when finishing the qc
>>from EH. Note that other advanced EH stuff like reconfiguring transport
>>speed also requires retrying, so we will surely have a mechanism for
>>retrying failed qc's from EH.
>
>
> What is needed is autosense simulation for ATA, so that SCSI Core doesn't
> know that the device doesn't support autosense.
>
> So, before a failed command reaches SCSI Core recovery, it should pass by
> ATA layer recovery to get sense.
>
> Note: if you send another command for execution after the failed command
> _and_ no autosense is provided, then any sense data is lost -- this is further
> subject to more rules set forth in SAM and SPC.
>

IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
mapping as long as possible. And, in the suggested framework, it's
guaranteed that no other command can come inbetween CHECK_SENSE and
REQUEST_SENSE.

Requesting sense from EH, calling scsi_decide_disposition() on the
sense and following the verdict should achieve the same effect as
emulating autosense. Is there any compelling reason to break one qc to
one command mapping?

--
tejun