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