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

[Jose Paulo Moitinho de Almeida]

On Thursday 04 October 2001 21:01, abel deuring wrote:
> Jose Paulo Moitinho de Almeida wrote:
> > Hello
> >
>.....
>
> 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.)
>

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
sense 0 0 0 0 0 0 0 0
len=0 sbp 68 22 42 8 ff ff ff ff
sb_len_wr 0

using the following piece of code

    printk(KERN_INFO "masked_status %x driver_status %x\n", 
          hp->masked_status, hp->driver_status);
    printk(KERN_INFO "sense %x %x %x %x %x %x %x %x\n", srp->sense_b[0], 
          srp->sense_b[1], srp->sense_b[2], srp->sense_b[3], 
          srp->sense_b[4], srp->sense_b[5], srp->sense_b[6], srp->sense_b[7]);
        if ((CHECK_CONDITION & hp->masked_status) ||
            (DRIVER_SENSE & hp->driver_status)) {
            int sb_len = sizeof(dummy_cmdp->sr_sense_buffer);
            sb_len = (hp->mx_sb_len > sb_len) ? sb_len : hp->mx_sb_len;
            len = 8 + (int)srp->sense_b[7]; /* Additional sense length field*/
            len = (len > sb_len) ? sb_len : len;
            if ((err = verify_area(VERIFY_WRITE, hp->sbp, len)))
                goto err_out;
            __copy_to_user(hp->sbp, srp->sense_b, len);
            hp->sb_len_wr = len;
        }
    }
    printk(KERN_INFO "len=%d sbp %x %x %x %x %x %x %x %x\n", hp->sb_len_wr, 
                hp->sbp[0], hp->sbp[1], hp->sbp[2],
                hp->sbp[3], hp->sbp[4], hp->sbp[5], hp->sbp[6], hp->sbp[7]);
    printk(KERN_INFO "sb_len_wr %x\n", hp->sb_len_wr);                        
    if (hp->masked_status || hp->host_status || hp->driver_status)
          hp->info |= SG_INFO_CHECK;                            

So hrd.info ands with SG_INFO_CHECK and the sense buffer is sent to the 
handler.

This dump lead me to the conclusion that the error was downstream, but 
perhaps I am wrong. 

Should sg.c be modified, so that when SG_INFO_CHECK is set, the 
initialisation of the sense_buffer is done? 

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

Regards

Ze Paulo

PS: Most probably I will not be able to read my email until next Monday. 
Sorry for being so long, but didn't want to forget anything.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sane_log.bz2
Type: application/x-bzip2
Size: 1348 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20011004/7e419d1f/attachment.bin>