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
