SG_BIG_BUFF, glibc 2.1 weirdness ...

Andreas Beck (becka@rz.uni-duesseldorf.de)
Sat, 14 Aug 1999 18:51:10 +0200

Hi folks. I just went almost mad tracking a very strange problem with sane
1.0.0, kernel 2.2.5 and glibc 2.1. I do not know, if it is fixed in 1.0.1.
If so, please disregard this mail.

O.K. - the problem is as follows:

I wanted to increase SG_BIG_BUFF to get less scanner stops and thus increase
throughput.

Error #1: I had been told, that 256k were safe. This is correct, but only
for Linux/alpha. The correct boundary is 32*PAGE_SIZE, wich is 4k*32=128k
for Intel, but 8k*32=256k for Alpha.

We should put that information in a README within SANE, not in the
sg-readme, which is pretty obscure to find.

The symptom of that is, that the backends quit with "out of memory", if you
go above the treshold given.

Error #2: If you compile the SCSI generic support as a module, the /proc
entry does not get created, causing sane not to recognize the larger value.

Now the big one that made me pull my hair:

Glibc installs its _own_ scsi.h and sg.h, which are different from the
kernel. Thus is you only edit sg.h from the Linux subdirectory you get very
very weird behaviour:

SANE recognizes the bigger buffer and the backends request the larger
blocks. However the allocated interim buffer in sanei_scsi.c is still
allocated with SG_BIG_BUFF in size. This causes a massive buffer overflow,
which in my case always resulted in a strange abnormal termination of
sanei_scsi_req_wait(), that caused the reader process to think it read 0
bytes and thus it stoped and resetted the scanner.

O.K. - what should we do about it ?

1. From 2.2.6 upwards, we have a new sg driver, which needs different
handling of buffer size management anyway. Thus the linux SCSI layer needs
a service interval anyway.

2. For the lower kernels, we should at least detect the abovementined
problem. Silently allowing to overflow internal buffers is rarely a good
idea. We should at least check, if the allocated buffer is big enough
for the transfer to work. If it isn't, abort with a clear error message.

IMHO we should even go one step further and stop using the statically
allocated data array, and rather use a dynamically allocated one, which
could use the dynamically found sanei_scsi_max_request_size.

Who maintains that file ? Still David ?

I'd volunteer to help on the coding, but I'll at least need a coauthor that
is willing to run 2.1.6 or above and take care for the support of the new
kernel sg driver code.
(The machine I run SANE on is a critical server, which needs proper ISDN
support, which is why I am reluctant to upgrade the kernel. I had lots and
lots of very strange problems with it the last time, and I don't feel like
searching for a working snapshot of the isdn subtree for another week.)

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com