[sane-devel] Scsi problem with Solaris 2.6

[Matto Marjanovic]

Hi, Henrik, Abel,

I'm catching up on this thread, too.  (When I first received the bug report,
 I was at the tail-end of finishing a Ph.D.  Don't expect too much more
 attention just yet -- now I am on vacation. :)

 >> Jun 25 13:08:25 cortex unix: esp: Cmd dump for Target 5 Lun 0:
 >> Jun 25 13:08:25 cortex unix: esp: cdblen=6, cdb=[ 0x8 0x0 0x0 0x0 0x91 0x0 ]
 >
 >That's a READ of just 0x91 (145) bytes; shouldn't cause any buffer 
 >overflow, but it's an odd number of bytes. A long shot: It could be that 
 >the SCG driver does not like to transfer an odd number of bytes.

Actually, it's a read of 145 *scanlines*, each of which is 900 bytes (in 
 this case).  That's what the 0x8 command means to these scanners.
 That makes 145 * 900 = 130500 bytes total, just under the 128k limit.

 >Matt and Henrik, I'm admittedly too lazy to look closer into the 
 >Microtek backend, but I guess that it is trying to read a complete scan 

And I am too lazy to look at the SCG driver to see what it does.  Henrik,
 is there some more debugging you can enable in the kernel driver so that
 we can see what it was doing *before* the error condition?

The implementation of sanei_scsi_cmd2() for the SOLARIS_SG_INTERFACE looks
 incomplete:  it makes no reference to the sense handler, and it simply
 returns SANE_STATUS_IO_ERROR for all error conditions.  (Thus, there is
 no way to access any sense data.)  Plus, it has no DBG()'s!

The logfile from the microtek backend is not very revealing:  simply an
 indeterminate SCSI error during the first read command.  Maybe this is
 one of those BUSY conditions (the scanner is still scanning 145 lines?),
 and the SCG driver is returning a busy signal/error instead of retrying
 the command itself?

-matt m.