Re: [RFC] libata new EH document

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux