[sane-devel] Additional SCSI status?

[Douglas Gilbert]

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