[sane-devel] Additional SCSI status?
Douglas Gilbert
dgilbert at interlog.com
Tue May 14 01:17:58 BST 2002
abel deuring wrote:
> abel deuring wrote:
>
>>abel deuring wrote:
>>
>>>Dave Close wrote:
>>>
>>>>I am dealing with a scanner that seems to return some of its status
>>>>outside the SCSI sense byte area. sanei_scsi reports this information
>>>>via DBG but doesn't provide it to the sense handler. The data is in the
>>>>SCSI header, which is physically adjacent to and preceding the sense
>>>>bytes in sanei_scsi.c, so I can get to it with some C tricks. But, of
>>>>course, those tricks could fail in a future SANE version. Is there a
>>>>better recommended solution?
>>>>
>>>>Here's the kind of debug output I'm seeing.
>>>>
>>>>[sanei_scsi] sanei_scsi_req_wait: read 64 bytes
>>>>[sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
>>>>[sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>[sanei_scsi] target status: 02 host status: 0000 driver status: 0018
>>>>[mybackend] sense=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>
>>>>The fourth line above shows target status and driver status. This
>>>>information does not appear to be available to the sense handler. If
>>>>sanei_scsi knows enough to call the sense handler in this case, and it
>>>>does, it should provide all the relevant data.
>>>>
>>>Dave,
>>>
>>>It does not make much sense to forward the words host status and driver
>>>status to the backend, because they are Linux-specific, while the
>>>backends should be able to work with a number of different OSes, which
>>>might provide completely different status information.
>>>
>>>I've inserted the DBG statements, because it makes bug tracing more
>>>convenient: If host status or driver status are non-zero, one should
>>>check for possible inconsistencies in the SCSI command sent (e.g., wrong
>>>CDB length, wrong data length), for possible bugs in sanei_scsi.c or in
>>>the backend; if things look fine, it's time to ask the kernel developers
>>>for help.
>>>
>
> ... and now I have checked, what target status == 2 means: CONDITION
> MET, says the SCSI 2 draft. So, sanei_scsi_req_wait should not return an
> error. The only puzzling thing is that driver status is non-zero; the
> corresponding #defines in linux/scsi/scsi.h are SUGGEST_RETRY and
> DRIVER_SENSE...
>
> You could try to simply ignore the driver status in sanei_scsi_req_wait.
> Lines 2191ff are currently:
>
> /* status bits INTERMEDIATE and CONDITION MET should not
> result in an error; neither should reserved bits
> */
> else if ( ((req->sgdata.sg3.hdr.status & 0x2a) == 0)
> && (req->sgdata.sg3.hdr.host_status == SG_ERR_DID_OK)
> && (req->sgdata.sg3.hdr.driver_status == SG_ERR_DRIVER_OK))
> status = SANE_STATUS_GOOD;
> else
> status = SANE_STATUS_IO_ERROR;
>
> Replacing this with
>
> else if ((req->sgdata.sg3.hdr.status & 0x2a) == 0)
> status = SANE_STATUS_GOOD;
> else
> status = SANE_STATUS_IO_ERROR;
>
> might work.
>
> Doug, can you tell us, when and why SUGGEST_RETRY and DRIVER_SENSE are
> set?
Abel,
The sg driver just sends back what it gets. As noted in the
sg documentation ( http://tldp.org/HOWTO/SCSI-Generic-HOWTO/x255.html )
the 'status' (and 'masked_status') fields are sometimes cleared
even though the sense_buffer is valid. The appropriate condition is:
if ((sg3.hdr.status & 0x2) ||
(SG_ERR_DRIVER_SENSE == (sg3.hdr.driver_status & 0xf)))
/* then the sense_buffer is valid */
Doug Gilbert
More information about the sane-devel
mailing list