kopia lustrzana https://gitlab.com/sane-project/website
262 wiersze
9.6 KiB
HTML
262 wiersze
9.6 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
||
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
||
<HTML>
|
||
<HEAD>
|
||
<TITLE>sane-devel: Re: [dev] sanei_scsi.c and Linux versions < 2.2.7</TITLE>
|
||
<META NAME="Author" CONTENT="Douglas Gilbert (dgilbert@interlog.com)">
|
||
<META NAME="Subject" CONTENT="Re: [dev] sanei_scsi.c and Linux versions < 2.2.7">
|
||
</HEAD>
|
||
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
||
<H1>Re: [dev] sanei_scsi.c and Linux versions < 2.2.7</H1>
|
||
<!-- received="Sun Jul 15 20:04:20 2001" -->
|
||
<!-- isoreceived="20010716030420" -->
|
||
<!-- sent="Sun, 15 Jul 2001 23:18:20 -0400" -->
|
||
<!-- isosent="20010716031820" -->
|
||
<!-- name="Douglas Gilbert" -->
|
||
<!-- email="dgilbert@interlog.com" -->
|
||
<!-- subject="Re: [dev] sanei_scsi.c and Linux versions < 2.2.7" -->
|
||
<!-- id="3B525CFC.5301A157@interlog.com" -->
|
||
<!-- inreplyto="3B51C4F0.76B7AAA8@gmx.net" -->
|
||
<STRONG>From:</STRONG> Douglas Gilbert (<A HREF="mailto:dgilbert@interlog.com?Subject=Re:%20[dev]%20sanei_scsi.c%20and%20Linux%20versions%20<%202.2.7&In-Reply-To=<3B525CFC.5301A157@interlog.com>"><EM>dgilbert@interlog.com</EM></A>)<BR>
|
||
<STRONG>Date:</STRONG> Sun Jul 15 2001 - 20:18:20 PDT
|
||
<P>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0136.html">John Profic: "Xsane Russsian translation & other questions"</A>
|
||
<UL>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0134.html">Henning Meier-Geinitz: "Re: Scanning with Mustek"</A>
|
||
<LI><STRONG>In reply to:</STRONG> <A HREF="0133.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0138.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0138.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#135">[ date ]</A>
|
||
<A HREF="index.html#135">[ thread ]</A>
|
||
<A HREF="subject.html#135">[ subject ]</A>
|
||
<A HREF="author.html#135">[ author ]</A>
|
||
</UL>
|
||
<HR NOSHADE><P>
|
||
<!-- body="start" -->
|
||
<P>
|
||
abel deuring wrote:
|
||
<BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Henning Meier-Geinitz wrote:
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > Hi,
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > I have some comments/questions on the sg buffer size on Linux kernels
|
||
</EM><BR>
|
||
<EM>> > before 2.2.7 (2.2.5 in this case). I got a bug report for this one. I
|
||
</EM><BR>
|
||
<EM>> > know this could be fixed by increasing the buffer size in the kernel
|
||
</EM><BR>
|
||
<EM>> > includes or by telling the backend (mustek in this case) not to use
|
||
</EM><BR>
|
||
<EM>> > more than 32k.
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > 1) In README there is a comment: "--enable-scsibuffersize and
|
||
</EM><BR>
|
||
<EM>> > SANE_SG_BUFFERSIZE have no effect for the Mustek, Umax and
|
||
</EM><BR>
|
||
<EM>> > Sharp backends.". This is not true, at least for the mustek
|
||
</EM><BR>
|
||
<EM>> > backend. In this backend you can set the buffer size in the config
|
||
</EM><BR>
|
||
<EM>> > file, but if one of the two methods above is used, the buffer size
|
||
</EM><BR>
|
||
<EM>> > is not bigger then the specified. E.g. mustek.conf: buffersize=128
|
||
</EM><BR>
|
||
<EM>> > (on kilobytes), SANE_SG_BUFFERSIZE=32768 --> real (maximum)
|
||
</EM><BR>
|
||
<EM>> > buffer size = 32768.
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > 2) Is there any way to detect from a backend how big the available
|
||
</EM><BR>
|
||
<EM>> > buffersize is? I'm using sanei_scsi_open extended and it tells me
|
||
</EM><BR>
|
||
<EM>> > that 128 k is ok even if the kernel doesn't support it. So the
|
||
</EM><BR>
|
||
<EM>> > question is: Must the user set the size to 32k manually (or modify
|
||
</EM><BR>
|
||
<EM>> > the kernel) or is there some other way?
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Hi Henning,
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> You are right; it should read "--enable-scsibuffersize and
|
||
</EM><BR>
|
||
<EM>> SANE_SG_BUFFERSIZE have no effect for the Mustek, Umax and Sharp
|
||
</EM><BR>
|
||
<EM>> backends, if a suffiently new SG driver is being used." (Sorry, I don't
|
||
</EM><BR>
|
||
<EM>> know, when exactly the ioctl calls SG_[GS]ET_RESERVED_SIZE were
|
||
</EM><BR>
|
||
<EM>> introduced)
|
||
</EM><BR>
|
||
<P>Abel,
|
||
<BR>
|
||
The SG_SET_RESERVED_SIZE ioctl became fully operational
|
||
<BR>
|
||
in lk 2.2.10 [sg version 2.1.34 1999/6/3]. Both the SET
|
||
<BR>
|
||
and the GET were there from lk 2.2.6 but the SET was
|
||
<BR>
|
||
silently ignored until lk 2.2.10 .
|
||
<BR>
|
||
<P><EM>> For old SG drivers, which don't support these ioctl calls,
|
||
</EM><BR>
|
||
<EM>> and which also don't have the pseudo file /proc/sys/kernel/sg-big-buff,
|
||
</EM><BR>
|
||
<EM>> sanei_scsi_open_extended indeed must use sanei_scsi_max_request_size,
|
||
</EM><BR>
|
||
<EM>> which in turn can be set by --enable-scsibuffersize and
|
||
</EM><BR>
|
||
<EM>> SANE_SG_BUFFERSIZE.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> If both --enable-scsibuffersize and SG_BIG_BUFF are set to 128 kB during
|
||
</EM><BR>
|
||
<EM>> Sane compilation, while SG_BIG_BUFF is set the default 32kB during
|
||
</EM><BR>
|
||
<EM>> kernel compilation, you'll get the old well known inconsistency for the
|
||
</EM><BR>
|
||
<EM>> old SG drivers. The only way to fix this is to set SANE_SG_BUFFERSIZE or
|
||
</EM><BR>
|
||
<EM>> to avoid the inconsistency.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > 3) Here is a log from the failing command:
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > [mustek] reader_process: buffer 1: entering read request for 65484 bytes (buffer 1)
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi_req_enter2: Command: 28 00 00 00 00 00 00 00 6b 00
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] scsi_req_enter: entered 0x4038b008
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi.issue: 0x4038b008
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi.issue: bad write (errno=12) Nicht gen<65>gend Hauptspeicher verf<72>gbar -1
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi.issue: SG_BIG_BUF inconsistency? Check file PROBLEMS.
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] scsi_req_enter: queue_used: 0, queue_max: 1
|
||
</EM><BR>
|
||
<EM>> > [mustek] reader_process: buffer 1: entered (line 107 of 835, buffer 1)
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > Wouldn't it be nicer to return an error from sanei_scsi_req_enter
|
||
</EM><BR>
|
||
<EM>> > instead of ignoring the situation? The error comes up later when
|
||
</EM><BR>
|
||
<EM>> > waiting for the buffer:
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > [mustek] reader_process: buffer 1: waiting for request to be ready
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi_req_wait: waiting for 0x4038b008
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi.issue: 0x4038b008
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] issue: ENOMEM - cannot queue SCSI command. Trying again later.
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] sanei_scsi.issue: 0x403ac008
|
||
</EM><BR>
|
||
<EM>> > [sanei_scsi] issue: ENOMEM - cannot queue SCSI command. Trying again later.
|
||
</EM><BR>
|
||
<EM>> > [mustek] reader_process: failed to read data, status: Out of memory, buffer: 1
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Well, the error report could of course be added to sanei_scsi_req_enter,
|
||
</EM><BR>
|
||
<EM>> but a backend should check for this error in sanei_scsi_req_wait too: If
|
||
</EM><BR>
|
||
<EM>> you queue two or more commands and the low level driver does not support
|
||
</EM><BR>
|
||
<EM>> command queueing, sanei_scsi_req_enter puts the second and following
|
||
</EM><BR>
|
||
<EM>> commands into its internal queue, so it cannot return an error from the
|
||
</EM><BR>
|
||
<EM>> SG driver.
|
||
</EM><BR>
|
||
<P>The reserved buffer is only good for one SCSI command
|
||
<BR>
|
||
at a time (per file descriptor) and only if it is big
|
||
<BR>
|
||
enough to hold the size of transfer being requested.
|
||
<BR>
|
||
<P>Thus when commands are queued there is a risk that
|
||
<BR>
|
||
subsequent commands will fail with ENOMEM. This "out of
|
||
<BR>
|
||
memory" situation is more likely to occur with ISA
|
||
<BR>
|
||
SCSI adapters which can only use the bottom 16 MB of
|
||
<BR>
|
||
memory for DMA. This is not a hard error and should
|
||
<BR>
|
||
not be treated as such [IMO]. The reserve buffer
|
||
<BR>
|
||
more or less guarantees SANE can queue 1 command.
|
||
<BR>
|
||
If memory is not available to queue 2 or more commands
|
||
<BR>
|
||
then wait ....
|
||
<BR>
|
||
<P>Doug Gilbert
|
||
<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?Subject=Re:%20[dev]%20sanei_scsi.c%20and%20Linux%20versions%20<%202.2.7&In-Reply-To=<3B525CFC.5301A157@interlog.com>">majordomo@mostang.com</A>
|
||
</PRE>
|
||
<P><!-- body="end" -->
|
||
<HR NOSHADE>
|
||
<UL>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0136.html">John Profic: "Xsane Russsian translation & other questions"</A>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0134.html">Henning Meier-Geinitz: "Re: Scanning with Mustek"</A>
|
||
<LI><STRONG>In reply to:</STRONG> <A HREF="0133.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0138.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0138.html">abel deuring: "Re: [dev] sanei_scsi.c and Linux versions < 2.2.7"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#135">[ date ]</A>
|
||
<A HREF="index.html#135">[ thread ]</A>
|
||
<A HREF="subject.html#135">[ subject ]</A>
|
||
<A HREF="author.html#135">[ author ]</A>
|
||
</UL>
|
||
<!-- trailer="footer" -->
|
||
<HR NOSHADE>
|
||
<P>
|
||
<SMALL>
|
||
<EM>
|
||
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
||
: <EM>Sun Jul 15 2001 - 20:09:39 PDT</EM>
|
||
</EM>
|
||
</SMALL>
|
||
</BODY>
|
||
</HTML>
|