Re: problems increasing SG_BIG_BUFF

Douglas Gilbert (dgilbert@interlog.com)
Sun, 13 Jun 1999 10:13:43 -0400

Petter Reinholdtsen wrote:
>
> [Andreas Buesching]
> > 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).

I think sane logic tries to look at '/proc/sys/kernel/sg-big-buff'
and if it cannot find it, uses the SG_BIG_BUFF define. The former
can only be found when sg is built into the kernel (ie not a
module). In the new sg driver, SG_BIG_BUFF is _not_ the value
fed into '/proc/sys/kernel/sg-big-buff'. So if you are using the
new sg driver (see below for which kernel versions it is in) then
making the sg driver a module may give you the effect you want with
sane.

> I beleave the newer kernel SCSI Generic (sq) driver ignores this
> define, and allows setting the max buffer size on a per-session basis.

That is correct using the SG_SET_RESERVED_SIZE ioctl. The most recent
sg version (2.1.34 discussed in the URL below) has a define called
SG_DEF_RESERVED_SIZE for increasing the default buffer size associated
with each sg device file descriptor. SG_BIG_BUFF is still there for
the amusement of apps that look at it, but it is not acted upon
internally by the sg driver. Buffers larger than the reserved buffer
size can be requested (for a particular SCSI command) but there is
a chance kernel memory will not be available. [This "chance" is more
likely if you are using a SCSI ISA adapater.] For applications like
sane this may be recoverable, it is a more serious problem for apps
that burn CDs.

> Look at <URL:http://www.torque.net/sg/> for more info. I'm not sure
> if the driver is included in the kernel distribution yet, so take this
> info with a grain of salt. :-)

The original Linux sg driver is in all 2.0 series kernels and remained
in the 2.2 series up to and including 2.2.5 . Hence recent distributions
like RH6.0 and SUSE(?) contain the original sg driver. The sg driver
referred to in http://www.torque.net/sg went into the productions
kernels in 2.2.6 . It is also in the 2.3 series.

The combination of the original sg driver in the 2.2 series (ie
2.2.0->2.2.5) built as a module and an increased SG_BIG_BUFF (to
128KB say) has a reasonable probability of an oops (due to out of
memory). This "feature" was the main reason the original driver
was replaced. [BTW The best way to get around the above problem
is to build the sg driver into the kernel (ie not a module).]

Doug Gilbert
sg maintainer

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