[sane-devel] [dev] CVS tree closed for release

[abel deuring]

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