Douglas Gilbert wrote: > > abel deuring wrote: > > ... 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...
Doug and, Dave ...the stuff above was again nonsense. I was really too tired yesterday... 2 means check condition... > > > > 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 */ Ok, that's one more point to be added to a rewrite of sanei_scsi, as it would be to return something like SANE_STATUS_RETRY to the backend, if that's suggested by the OS. But for the current sanei_scsi layer, I don't see any way to fix Dave's problem without breaking compatibility with other backends. Abel
