[sane-devel] Problem with empty sense buffer in sanei_scsi (linux+hpusbscsi+vuescan)?

[abel deuring]

Douglas Gilbert wrote:
> 
> Jose Paulo Moitinho de Almeida wrote:
> > I now have the log, using the original sg driver, which is attached and
> > states:
> >
> > a) "sanei_scsi_open: using new SG header structure";
> >
> > b) "sense buffer: 68 22 42 08 ff ff ff ff 00 00 00 00 00 00 00 00"
> >
> > After reading Abel's message, rereading the code and looking at the log I
> > think it is safe to say that the problem is here:
> >
> >      if (   ((req->sgdata.sg3.hdr.info & SG_INFO_CHECK) != 0)
> >              || (req->sgdata.sg3.hdr.sb_len_wr > 0 &&
> >               ((req->sgdata.sg3.sense_buffer[0] & 0x7f) != 0)))
> >
> > I don't have the scanner here, but from the log I had when tracing the
> > problem, while in drivers/scsi/sg.c, sg_new_read, I dumped the following info:
> >
> > masked_status 8 driver_status 0
> 
> Paulo,
> The problem starts here, a masked_status of 8 corresponds
> to a SCSI status of INTERMEDIATE. This implies the command
> sent to the scanner had the link bit set in the control
> field which is the last byte in every command descriptor
> block. Perhaps the SANE backend driver wanted to invoke
> linked commands, more likely, it is a mistake by the
> backend driver. Anyway that SCSI status does not
> trigger auto-sense and therefore has no sense buffer
> associated with it. The lack of sense buffer is indicated
> by the sb_len_wr == 0.

With my latest patch to sanei_scsi.c, the wrong call of the sense
handler should no longer happen. But I'm afraid, that we have another
problem: The returns also driver_status=7, and this smells like an
error...

> I have just put some more words in the sg documentation
> (soon to be at: http://www.torque.net/sg/p/sg_v3_ho.html )
> to emphasize that SG_INFO_CHECK does not always imply that
> there will be a sense buffer.

This wrong interpretation of SG_INFO_CHECK in sanei_scsi.c should be
fixed with my latest patch. 

> Yes, that is correct. To get around this, apps like cdrecord
> and paranoia would pre-fill the sense buffer with zeroes and
> then look for a change when the command completed.

So I should add another patch for the SG driver version 2. Just a
question (Ok, I'm too lazy to look into the cdrecord and SG sources :):
Is a simple memset(hdr, 0, sizeof(sg_header)) enough, i.e., does the SG
driver copy the header as received from the write call, and returns this
data (of course with appropriate status bits etc set) in the following
read call?

Ze Paulo wrote:

> > > Should sg.c be modified, so that when SG_INFO_CHECK is set, the
> > > initialisation of the sense_buffer is done?
> >
> > I have just put some more words in the sg documentation
> > (soon to be at: http://www.torque.net/sg/p/sg_v3_ho.html )
> > to emphasize that SG_INFO_CHECK does not always imply that
> > there will be a sense buffer.
> 
> > > The possibility that there may be a problem somewhere else should not be
> > > excluded either. I am using a driver which is "fresh from the oven".
> >
> 
> I can add that I had exactly the same result using the now "officially
> experimental" version of hpusbscsi that is in 2.4.12. Just adding the
> following patch to drivers/scsi/sg.c vuescan works fine. I know that I am not
> correcting the true source of the error!

Well, as long as we don't get a response from Ed, this is the only way
you can fix the problem, so I think, you should use this patch to the SG
driver. But I'd like to get the problem fixed in a better way...

> > Yes, that is correct. To get around this, apps like cdrecord
> > and paranoia would pre-fill the sense buffer with zeroes and
> > then look for a change when the command completed.
> >
> 
> Would that be an alternative, or is it better to try Abel's patch?

I think that we need both; at least if we want the scanner also to be
usable with older version of the SG driver.

Abel