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