kopia lustrzana https://gitlab.com/sane-project/website
92 wiersze
4.9 KiB
HTML
92 wiersze
4.9 KiB
HTML
<!-- received="Sun Jun 13 07:06:37 1999 PDT" -->
|
||
<!-- sent="Sun, 13 Jun 1999 10:13:43 -0400" -->
|
||
<!-- name="Douglas Gilbert" -->
|
||
<!-- email="dgilbert@interlog.com" -->
|
||
<!-- subject="Re: problems increasing SG_BIG_BUFF" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="problems increasing SG_BIG_BUFF" -->
|
||
<title>sane-devel: Re: problems increasing SG_BIG_BUFF</title>
|
||
<h1>Re: problems increasing SG_BIG_BUFF</h1>
|
||
<b>Douglas Gilbert</b> (<a href="mailto:dgilbert@interlog.com"><i>dgilbert@interlog.com</i></a>)<br>
|
||
<i>Sun, 13 Jun 1999 10:13:43 -0400</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#69">[ date ]</a><a href="index.html#69">[ thread ]</a><a href="subject.html#69">[ subject ]</a><a href="author.html#69">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0070.html">Norihiko Sawa: "EPSON GT7-000 transparency unit patch"</a>
|
||
<li> <b>Previous message:</b> <a href="0068.html">Peter Kirchgessner: "Re: "scsi HP" in hp.conf"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0047.html">Andreas Buesching: "problems increasing SG_BIG_BUFF"</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0243.html">Rainer Krienke: "Re: problems increasing SG_BIG_BUFF"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Petter Reinholdtsen wrote:<br>
|
||
<i>> </i><br>
|
||
<i>> [Andreas Buesching]</i><br>
|
||
<i>> > So I increased SG_BIG_BUFF and compiled the kernel and sane again.</i><br>
|
||
<i>> > The result was: nothing. Some months ago when I used an older kernel</i><br>
|
||
<i>> > (2.0.x), there was an result: My scanner did not stop every 5mm to</i><br>
|
||
<i>> > transfer the data (it sounds horrible if it stops every 5mm).</i><br>
|
||
<p>
|
||
I think sane logic tries to look at '/proc/sys/kernel/sg-big-buff'<br>
|
||
and if it cannot find it, uses the SG_BIG_BUFF define. The former<br>
|
||
can only be found when sg is built into the kernel (ie not a<br>
|
||
module). In the new sg driver, SG_BIG_BUFF is _not_ the value<br>
|
||
fed into '/proc/sys/kernel/sg-big-buff'. So if you are using the<br>
|
||
new sg driver (see below for which kernel versions it is in) then<br>
|
||
making the sg driver a module may give you the effect you want with<br>
|
||
sane.<br>
|
||
<br>
|
||
<i>> I beleave the newer kernel SCSI Generic (sq) driver ignores this</i><br>
|
||
<i>> define, and allows setting the max buffer size on a per-session basis.</i><br>
|
||
<p>
|
||
That is correct using the SG_SET_RESERVED_SIZE ioctl. The most recent<br>
|
||
sg version (2.1.34 discussed in the URL below) has a define called<br>
|
||
SG_DEF_RESERVED_SIZE for increasing the default buffer size associated<br>
|
||
with each sg device file descriptor. SG_BIG_BUFF is still there for<br>
|
||
the amusement of apps that look at it, but it is not acted upon<br>
|
||
internally by the sg driver. Buffers larger than the reserved buffer<br>
|
||
size can be requested (for a particular SCSI command) but there is<br>
|
||
a chance kernel memory will not be available. [This "chance" is more<br>
|
||
likely if you are using a SCSI ISA adapater.] For applications like<br>
|
||
sane this may be recoverable, it is a more serious problem for apps<br>
|
||
that burn CDs.<br>
|
||
<p>
|
||
<i>> Look at <URL:<a href="http://www.torque.net/sg/">http://www.torque.net/sg/</a>> for more info. I'm not sure</i><br>
|
||
<i>> if the driver is included in the kernel distribution yet, so take this</i><br>
|
||
<i>> info with a grain of salt. :-)</i><br>
|
||
<p>
|
||
The original Linux sg driver is in all 2.0 series kernels and remained<br>
|
||
in the 2.2 series up to and including 2.2.5 . Hence recent distributions<br>
|
||
like RH6.0 and SUSE(?) contain the original sg driver. The sg driver <br>
|
||
referred to in <a href="http://www.torque.net/sg">http://www.torque.net/sg</a> went into the productions <br>
|
||
kernels in 2.2.6 . It is also in the 2.3 series.<br>
|
||
<p>
|
||
The combination of the original sg driver in the 2.2 series (ie<br>
|
||
2.2.0->2.2.5) built as a module and an increased SG_BIG_BUFF (to <br>
|
||
128KB say) has a reasonable probability of an oops (due to out of <br>
|
||
memory). This "feature" was the main reason the original driver <br>
|
||
was replaced. [BTW The best way to get around the above problem<br>
|
||
is to build the sg driver into the kernel (ie not a module).]<br>
|
||
<p>
|
||
Doug Gilbert<br>
|
||
sg maintainer<br>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0070.html">Norihiko Sawa: "EPSON GT7-000 transparency unit patch"</a>
|
||
<li> <b>Previous message:</b> <a href="0068.html">Peter Kirchgessner: "Re: "scsi HP" in hp.conf"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0047.html">Andreas Buesching: "problems increasing SG_BIG_BUFF"</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0243.html">Rainer Krienke: "Re: problems increasing SG_BIG_BUFF"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|