Tim Waugh wrote: > > On Sun, Nov 04, 2001 at 02:47:19PM +0100, abel deuring wrote: > > > Eric observed this for kernel 2.4.9; I saw it for 2.4.5 and 2.4.13, > > while 2.4.0 works fine. > > > > I know that Sane 1.0.6 is due to be released, but I'm afraid that we'll > > get more and more error reports as people will install newer kernels. > > OTOH, the fix is really simple. It is sufficient to disable lines 2179 > > ..2183 in sanei_scsi.c: > > Is the kernel fix known?
Tim, I'm not aware of any fix. But it was only yesterday evening sure that I was sure that there is a serious problem somewhere in the Linux SCSI system. I wrote a more detailed description of my observations to Doug Gilbert, but haven't yet received a response. But he might be on weekend holidays ;) Here it is again. Assume that a number of SCSI READ commands (0x28) to an SG device, all with identical parameters (except perhaps the last one or two commands), are issued this way: sg_write(...) [1] sg_write(...) [2] sg_read(...) [1] sg_write(...) [3] sg_read(...) [2] sg_write(...) [4] sg_read(...) [3] sg_write(...) [5] sg_read(...) [4] ... sg_write(...) [n] sg_read(...) [n-1] sg_read(...) [n] Then, every even-numbered read call returns resid != 0, specifically, resid == 176. The Sharp backend assumes that is must issue another READ command at the end of the scan; for this command, the scanner returns an error telling that it could not deliver exactly N * 176 bytes. If I deliberately set the field dxfer_len in struct sg_io_hdr_t to a larger value than the data size in the SCSI command, the odd-numbered calls return the expected resid value, while the even-numbered calls return 176 as without the inconststend information in dxfer_len and the SCSI command data size. Eric had this problem with lk 2.4.9 and the aic7xxx driver; I noticed it for lk 2.4.5 and 2.4.13, in combination with both the sym53c8xx driver and the aic7xxx driver. Abel
