kopia lustrzana https://gitlab.com/sane-project/website
422 wiersze
15 KiB
HTML
422 wiersze
15 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: SCSI problems with SANE 1.0.5, Linux 2.4.x and</TITLE>
|
|
<META NAME="Author" CONTENT="abel deuring (a.deuring@satzbau-gmbh.de)">
|
|
<META NAME="Subject" CONTENT="Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering</H1>
|
|
<!-- received="Sat Jul 7 09:12:27 2001" -->
|
|
<!-- isoreceived="20010707161227" -->
|
|
<!-- sent="Sat, 07 Jul 2001 19:31:58 +0200" -->
|
|
<!-- isosent="20010707173158" -->
|
|
<!-- name="abel deuring" -->
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|
<!-- subject="Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering" -->
|
|
<!-- id="3B47478E.20695548@satzbau-gmbh.de" -->
|
|
<!-- inreplyto="20010707145729.B11412@vortex.swb.de" -->
|
|
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20SCSI%20problems%20with%20SANE%201.0.5,%20Linux%202.4.x%20and%20double%20buffering&In-Reply-To=<3B47478E.20695548@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Sat Jul 07 2001 - 10:31:58 PDT
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0079.html">Henning Meier-Geinitz: "Re: Compiling problems on Redhat 7.0"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0075.html">Henning Meier-Geinitz: "SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#80">[ date ]</A>
|
|
<A HREF="index.html#80">[ thread ]</A>
|
|
<A HREF="subject.html#80">[ subject ]</A>
|
|
<A HREF="author.html#80">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Henning Meier-Geinitz wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Hi,
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I got several reports of SCSI problems with Mustek scanners in the
|
|
</EM><BR>
|
|
<EM>> last days. I don't think that these are mustek-bugs. The bug reporters
|
|
</EM><BR>
|
|
<EM>> provided the following common facts:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> * Linux 2.4.x
|
|
</EM><BR>
|
|
<EM>> * a SCSI controller that has a queue depth of 1 (e.g. Adaptec 1520)
|
|
</EM><BR>
|
|
<EM>> * SuSe 7.x (may be coincidence)
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> They tried to scan an image but they only get the first stripe of
|
|
</EM><BR>
|
|
<EM>> aprox. 64k that is repeated until the page is completely scanned. The
|
|
</EM><BR>
|
|
<EM>> scanner stops after this first stripe. Sometimes the system freezes
|
|
</EM><BR>
|
|
<EM>> completely, sometimes there is only an error message and sometimes no
|
|
</EM><BR>
|
|
<EM>> error is output at all.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I tried to reproduce this bug but couldn't until I did the following:
|
|
</EM><BR>
|
|
<EM>> rename /usr/include/scsi/sg.h to something else. After recompile
|
|
</EM><BR>
|
|
<EM>> sanei_scsi.c seems to use the kernel headers from /usr/src/linux
|
|
</EM><BR>
|
|
<EM>> (which are the right ones for my current kernel 2.4.5). I'm using
|
|
</EM><BR>
|
|
<EM>> Debian 2.2.
|
|
</EM><BR>
|
|
|
|
<BR>
|
|
So the error does not occur, if /usr/include/scsi/sg.h exists? (for
|
|
<BR>
|
|
more, see below)
|
|
<BR>
|
|
<P>
|
|
<BR>
|
|
[...]
|
|
<BR>
|
|
<EM>> [mustek] SANE mustek backend version 1.0 build 107 from sane-backends-1.0.5
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open: sanei_scsi_max_request_size=131072 bytes
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open: SG driver version: 30117
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open_extended: using 8192 bytes as SCSI buffer
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] trying to enable low level command queueing
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 1
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run time
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_open: using new SG header structure
|
|
</EM><BR>
|
|
<EM>> --- The last line isn't printed if I use /usr/include/scsi/sg.h
|
|
</EM><BR>
|
|
|
|
<BR>
|
|
This means that /usr/include/scsi/sg.h does not define SG_IO and other
|
|
<BR>
|
|
stuff necessary for SG driver 3.x. In this case, sanei_scsi.c is
|
|
<BR>
|
|
compiled only for SG 2.x. Since the newer SG drivers support the old
|
|
<BR>
|
|
interface too, everything should work -- but the new interface is much
|
|
<BR>
|
|
more "clean": It does not need to guess the size of a SCSI command
|
|
<BR>
|
|
block; sanei_scsi_req_enter does not need to copy command block and
|
|
<BR>
|
|
write data into a new buffer which starts with the old SG header.
|
|
<BR>
|
|
Douglas Gilbert can certainly name a few other advances :)
|
|
<BR>
|
|
|
|
<BR>
|
|
So, if the error does occur, if /usr/include/scsi/sg.h exists, this
|
|
<BR>
|
|
might point to a problem in the parts of the SG driver for the new
|
|
<BR>
|
|
header structure ... or we have indeed a nasty bug in the queue
|
|
<BR>
|
|
management of sanei_scsi.c . I'll try to reproduce the problems
|
|
<BR>
|
|
tomorrow.
|
|
<BR>
|
|
|
|
<BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [mustek] attach: sending INQUIRY
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] scsi_req_enter: entered 0x80f6d88
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x80f6d88
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=7 max_active_device=1 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=48 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=8192 (res)sgat=0 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> rcv: id=0 blen=96 dur=10ms sgat=0 op=0x12
|
|
</EM><BR>
|
|
<EM>> --- Where does this come from? I can't find it in sanei_scsci.c.
|
|
</EM><BR>
|
|
|
|
<BR>
|
|
That's in function issue:
|
|
<BR>
|
|
|
|
<BR>
|
|
IF_DBG(if (DBG_LEVEL >= 255) system("cat /proc/scsi/sg/debug 1>&2");)
|
|
<BR>
|
|
|
|
<BR>
|
|
It was suggested by Douglas. The idea is to have debug information from
|
|
<BR>
|
|
Sane and from the SG driver in one place.
|
|
<BR>
|
|
<P><EM> > [...]
|
|
</EM><BR>
|
|
<EM>> [mustek] sane_start
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: buffer 1: entering read request for 64470 bytes (buffer 1)
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: buffer 1: entered (line 35 of 995, buffer 1)
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: buffer 2: entering read request for 64470 bytes (buffer 2)
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] scsi_req_enter: entered 0x81d4150
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x81d4150
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: buffer 2: entered (line 70 of 995, buffer 2)
|
|
</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 0x81b2d58
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x81b2d58
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=7 max_active_device=1 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=48 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=131072 (res)sgat=4 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> rcv: id=14 blen=64470 dur=2690ms sgat=2 op=0x08
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x81d4150
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=7 max_active_device=1 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=48 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=131072 (res)sgat=4 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> rcv: id=15 blen=64470 dur=0ms sgat=2 op=0x83
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
|
|
</EM><BR>
|
|
<EM>> --- Why is this only 64 bytes (that's printed for every req_wait even
|
|
</EM><BR>
|
|
<EM>> if the buffer is much bigger)?
|
|
</EM><BR>
|
|
|
|
<BR>
|
|
The "meaning" of the value returned by a read from an SG device changed
|
|
<BR>
|
|
with SG version 3.x. For SG version 1.x and 2.x, all information to be
|
|
<BR>
|
|
sent to/read from the device (SCSI command, read/write data, sense
|
|
<BR>
|
|
buffer, and a handful of status fields) is stuffed into one buffer.
|
|
<BR>
|
|
Accordingly read/write for an SG device return the size of this buffer.
|
|
<BR>
|
|
The SG drivers 3.x use a new header structure, which contains pointers
|
|
<BR>
|
|
to separate buffers for SCSI command, read/write data and sense buffer.
|
|
<BR>
|
|
Hence, read/write calls look like:
|
|
<BR>
|
|
|
|
<BR>
|
|
Sg_io_hdr cmd;
|
|
<BR>
|
|
/* setup the data for cmd */
|
|
<BR>
|
|
write(fd, &cmd, sizeof(Sg_io_hdr));
|
|
<BR>
|
|
read(fd, &cmd, sizeof(Sg_io_hdr));
|
|
<BR>
|
|
|
|
<BR>
|
|
regardless of the size of the read/write buffer, the calls return simply
|
|
<BR>
|
|
sizeof(Sg_io_hdr) (unless an error occurs).
|
|
<BR>
|
|
<P><EM> > [mustek]
|
|
</EM><BR>
|
|
reader_process: buffer 1 is ready, wanted 64470, got 64470 bytes
|
|
<BR>
|
|
<EM>> [mustek] reader_process: buffer 1: sending 64470 bytes to output_data
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: buffer 1: entering read request for 64470 bytes (buffer 3)
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> This goes on until the full page is scanned. No error occurs but the
|
|
</EM><BR>
|
|
<EM>> resulting image conatines the first buffer over and over again.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> >From a bug-reporter I got a debug log that's a bit different:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x80bcef0
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=9 max_active_device=3 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=144 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=131072 (res)sgat=4 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> act: id=12 blen=44208 t_o/elap=600000/40ms sgat=2 op=0x53
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] target status: 00 host status: 0007 driver status: 0000
|
|
</EM><BR>
|
|
<EM>> [mustek] sense_handler: got sense code 00 for fd 7 (arg = null)
|
|
</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 0x80bcef0
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x80bcef0
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=9 max_active_device=3 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=144 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=131072 (res)sgat=4 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> rcv: id=12 blen=44208 dur=260ms sgat=2 op=0x53
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi.issue: 0x80e3710
|
|
</EM><BR>
|
|
<EM>> dev_max(currently)=9 max_active_device=3 (origin 1)
|
|
</EM><BR>
|
|
<EM>> scsi_dma_free_sectors=144 sg_pool_secs_aval=320 def_reserved_size=32768
|
|
</EM><BR>
|
|
<EM>> >>> device=sg0 scsi0 chan=0 id=6 lun=0 em=0 sg_tablesize=255 excl=1
|
|
</EM><BR>
|
|
<EM>> FD(1): timeout=600000ms bufflen=131072 (res)sgat=4 low_dma=0
|
|
</EM><BR>
|
|
<EM>> cmd_q=1 f_packid=0 k_orphan=0 closed=0
|
|
</EM><BR>
|
|
<EM>> rb>> act: id=13 blen=44208 t_o/elap=600000/30ms sgat=2 op=0x53
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
</EM><BR>
|
|
<EM>> [sanei_scsi] target status: 00 host status: 0001 driver status: 0000
|
|
</EM><BR>
|
|
<EM>> [mustek] reader_process: failed to read data, status: Device busy, buffer: 1
|
|
</EM><BR>
|
|
<EM>> [...]
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> --- What's this funny error message?
|
|
</EM><BR>
|
|
|
|
<BR>
|
|
No idea...
|
|
<BR>
|
|
|
|
<BR>
|
|
Abel
|
|
<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:%20SCSI%20problems%20with%20SANE%201.0.5,%20Linux%202.4.x%20and%20double%20buffering&In-Reply-To=<3B47478E.20695548@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0079.html">Henning Meier-Geinitz: "Re: Compiling problems on Redhat 7.0"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0075.html">Henning Meier-Geinitz: "SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0081.html">Henning Meier-Geinitz: "Re: SCSI problems with SANE 1.0.5, Linux 2.4.x and double buffering"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#80">[ date ]</A>
|
|
<A HREF="index.html#80">[ thread ]</A>
|
|
<A HREF="subject.html#80">[ subject ]</A>
|
|
<A HREF="author.html#80">[ 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>Sat Jul 07 2001 - 09:14:00 PDT</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|