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. Abel
