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
