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

[abel deuring]

Jose Paulo Moitinho de Almeida wrote:
> 
> Hello
> 
> First the good news: I have managed to make my Minolta Scan Dual II work with
> vuescan under linux using the hpusbscsi driver in the ac series.
> 
> The not so good news is that I had to introduce  an hack in drivers/scsi/sg.c
> to achieve this. I think that the problem is related to sanei_scsi, which is
> used by vuescan.
> 
> The problem happens because sometimes there is junk in the sense buffer (not
> initialised) but sb_len_wr is zero, so the junk should not be accessed. I
> checked this by tracing the variables on drivers/scsi/sg.h and had no
> problems when I forced the initialisation of the sense buffer in the outgoing
> structure.
> 
> <Pardon>
> Until yesterday I had never opened sanei_scsi.c so forgive me for the
> mistakes...
> </Pardon>
> 
> Ed Hamrick says that "VueScan uses the sanei_scsi routines to do scsi i/o on
> Linux, and the SANEI_SCSI_Sense_Handler routine doesn't have an argument
> that contains the length of the sense buffer."
> 
> So I assume that the handler is being called when sb_len_wr is zero. In the
> version of sanei_scsi distributed with 1.0.5 I see an #ifdef SG_IO in
> sanei_scsi_req_wait which decides how to check for errors and, in certain
> conditions, uses sb_len_wr.

Jose,

The "#ifdef SG_IO" is used to determine, if sg.h for the SG driver
version 3.x is available. Only these newer versions of the SG driver
support the struct sg_io_hdr_t
wich has the field sb_len_wr. The older versions know only about struct
sg_header.

> 
> Can someone point me in which direction I should look? I just noticed that I
> should attach a dump (I have one at home....) but I have also noticed that
> the debug messages are similar on both portions of the code.

Maybe, but I think that older versions of the SG driver do not return
the length of sense data read from a device. (Douglas, can you confirm
this?)

Jose, it seems that you uncovered a serious problem in sanei_scsi.c --
but I'm afraid that a proper fix isn't that easy:

1. sanei_scsi.c passes the sense buffer to a callback function
(parameter sense_handler in sanei_scsi_open[_extended]) So a fix would
require patches to all backends that implement a sense handler.

2. As mentioned above, older versions of the Linux SG driver do not
return the length of the sense buffer. So, even if you would start to
patch sanei_scsi.c, the sense handlers would need to be aware that no
length information is available.

3. The patch needs to be applied to the implementations of
sanei_scsi_cmd resp. sanei_scsi_req_enter/sanei_scsi_req_wait for all
the operating systems supported by Sane.

An easier way might perhaps be to return some "obviously invalid data"
like a string of 0 or 0xff in the case that the SG driver or its
counterparts for other OS do not return a valid sense buffer. (BTW, does
Byte 0 of the sense buffer contain the value 0xf0 or 0x70? If not, this
could be used to determine, if a valid sense buffer is available.)

Abel