Re: [RFC] libata new EH document

[Tejun Heo <htejun@gmail.com>]

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