Monty (cdparanoia author) has a nice way around the
above directory problem:
#include <linux/../scsi/sg.h>
#include <linux/../scsi/scsi.h>
[An elegant hack!]
>
> problem:
> I tried to increase the generic-scsi buffer. The man-pages told me to change
> SG_BIG_BUFF. the new kernel uses another define (SG_SCATTER_SZ), but there are
> also these two lines:
>
> #define SG_BIG_BUFF SG_SCATTER_SZ /* for backward compatibility */
> /* #define SG_BIG_BUFF (SG_SCATTER_SZ * 8) */ /* =256KB, if you want */
>
> So I increased SG_BIG_BUFF and compiled the kernel and sane again.
> The result was: nothing. Some months ago when I used an older kernel (2.0.x),
> there was an result: My scanner did not stop every 5mm to transfer the data (it
> sounds horrible if it stops every 5mm).
>
> My question:
> Can anybody help me? How to increase the buffer?
>
Andreas,
You may like to try this ... go to
http://www.torque.net/sg
and download sg version 2.1.34 (you have version
2.1.32 in 2.2.9). In the new sg.h change the
SG_DEF_RESERVED_SIZE to 262144 and try that.
[This assumes that your SCSI adapter does scatter
gather which even most ISA ones do.]
While your at that web site you may be interested
in the documentation's section on "SG_BIG_BUFF and
friends".
BTW 2.2.9-ac3 also contains the most recent sg
driver.
In the new sg driver SG_BIG_BUFF exists for backward
compatibility (which doesn't extend to people
changing it :-) ). Internally the sg driver takes
no account of it. Some apps are fooled by it but not,
it would seem, sane.
Hopefully in the future the sane linux transport layer
will use the SG_SET_RESERVED_BUFFER ioctl() and sane's
documentation will stop recommending people hacking
the sg.h header file. Under 2.2 with the original
sg driver this is a very dangerous thing to do (ie
greatly increases the probably of an ENOMEM induced
oops, especially on modules).
Doug Gilbert
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com