kopia lustrzana https://gitlab.com/sane-project/website
396 wiersze
15 KiB
HTML
396 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: Problem with kernel 2.4ac9, ava1505, snapscan12</TITLE>
|
||
<META NAME="Author" CONTENT="abel deuring (a.deuring@satzbau-gmbh.de)">
|
||
<META NAME="Subject" CONTENT="Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4">
|
||
</HEAD>
|
||
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
||
<H1>Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4</H1>
|
||
<!-- received="Tue Jan 16 08:51:08 2001" -->
|
||
<!-- isoreceived="20010116165108" -->
|
||
<!-- sent="Tue, 16 Jan 2001 18:59:58 +0100" -->
|
||
<!-- isosent="20010116175958" -->
|
||
<!-- name="abel deuring" -->
|
||
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
||
<!-- subject="Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4" -->
|
||
<!-- id="3A648C1E.38EE1C42@satzbau-gmbh.de" -->
|
||
<!-- inreplyto="3A61FF59.39BC55C3@interlog.com" -->
|
||
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20Problem%20with%20kernel%202.4ac9,%20ava1505,%20snapscan1236s,%20sane1.0.4&In-Reply-To=<3A648C1E.38EE1C42@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
||
<STRONG>Date:</STRONG> Tue Jan 16 2001 - 09:59:58 PST
|
||
<P>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<UL>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0154.html">Joern Clausen: "Nikon LS-2000 with Solaris"</A>
|
||
<LI><STRONG>In reply to:</STRONG> <A HREF="0143.html">Douglas Gilbert: "Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0158.html">Henning Meier-Geinitz: "Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#155">[ date ]</A>
|
||
<A HREF="index.html#155">[ thread ]</A>
|
||
<A HREF="subject.html#155">[ subject ]</A>
|
||
<A HREF="author.html#155">[ author ]</A>
|
||
</UL>
|
||
<HR NOSHADE><P>
|
||
<!-- body="start" -->
|
||
<P>
|
||
Douglas Gilbert wrote:
|
||
<BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Erik Inge Bols<6C> wrote:
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > On Sun, 14 Jan 2001, Douglas Gilbert wrote:
|
||
</EM><BR>
|
||
<EM>> > >> [snapscan] request_sense
|
||
</EM><BR>
|
||
<EM>> > >> [snapscan] sense_handler(5, 0xbffff324, 0x8050c90)
|
||
</EM><BR>
|
||
<EM>> > >> [snapscan] sense_handler: sense key is invalid.
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > The problem was here. The aha152x.c driver filtered out request_sense
|
||
</EM><BR>
|
||
<EM>> > commands and always returned 0 on them. (At least that's my layman's
|
||
</EM><BR>
|
||
<EM>> > understanding of the problem.)
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > int aha152x_queue(Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
|
||
</EM><BR>
|
||
<EM>> > {
|
||
</EM><BR>
|
||
<EM>> > if(*SCpnt->cmnd == REQUEST_SENSE) {
|
||
</EM><BR>
|
||
<EM>> > SCpnt->result = 0;
|
||
</EM><BR>
|
||
<EM>> > done(SCpnt);
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > return SUCCESS;
|
||
</EM><BR>
|
||
<EM>> > }
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > return aha152x_internal_queue(SCpnt, 0, 0, 0, done);
|
||
</EM><BR>
|
||
<EM>> > }
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > Removing everything but the "return" line fixed the problem :)
|
||
</EM><BR>
|
||
<EM>> >
|
||
</EM><BR>
|
||
<EM>> > Thanks to Marcel Martin for the fix :)
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> This is interesting. The linux scsi subsystem (as does
|
||
</EM><BR>
|
||
<EM>> FreeBSD's CAM) implements "autosense" to get its sense
|
||
</EM><BR>
|
||
<EM>> buffer after a command has failed. This means that when
|
||
</EM><BR>
|
||
<EM>> a command like "test unit ready" is sent and it returns
|
||
</EM><BR>
|
||
<EM>> a "check condition" status code then the subsystem will
|
||
</EM><BR>
|
||
<EM>> automatically issue a "request sense" and give its
|
||
</EM><BR>
|
||
<EM>> response back as the sense buffer of the original command
|
||
</EM><BR>
|
||
<EM>> ("test unit ready" in this case).
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> So SANE backends shouldn't be issuing "request sense"
|
||
</EM><BR>
|
||
<EM>> commands IMHO. BTW only the first "request sense" gets
|
||
</EM><BR>
|
||
<EM>> the error response, so sending more of them is useless.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> It seems as though a problem that Arnold Schiller has
|
||
</EM><BR>
|
||
<EM>> sent me is very similar: a SnapScan1236/aha152x
|
||
</EM><BR>
|
||
<EM>> combination that locks up just after a "request sense"
|
||
</EM><BR>
|
||
<EM>> is sent to the scanner.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Anyway, the aha152x driver probably shouldn't be reacting
|
||
</EM><BR>
|
||
<EM>> the way it is.
|
||
</EM><BR>
|
||
<P>I think that J<>rgen Fischer patched the aha152x driver already.
|
||
<BR>
|
||
<P>I must admit that I am the one who insisted that the Snapscans are a
|
||
<BR>
|
||
little bit brain damaged, and that it would be preferable to have low
|
||
<BR>
|
||
level SCSI driver, which can handle a REQUEST SENSE command from user
|
||
<BR>
|
||
space.
|
||
<BR>
|
||
<P>This claim was purely based on reading the source files of the Snapscan
|
||
<BR>
|
||
backend. At present, I have a borrowed Snapscan 1236 at home, so I
|
||
<BR>
|
||
played a little bit with Sane and the scanner.
|
||
<BR>
|
||
<P>The main result is, that at least _this_ scanner works probably as
|
||
<BR>
|
||
described above by Douglas: The REQUEST SENSE command issued from the
|
||
<BR>
|
||
backend does not work as expected.
|
||
<BR>
|
||
<P>wait_scanner_ready is one of the functions of the backend using the
|
||
<BR>
|
||
REQUEST SENSE command (probably the most important):
|
||
<BR>
|
||
<P>static SANE_Status wait_scanner_ready (SnapScan_Scanner *pss)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
static char me[] = "wait_scanner_ready";
|
||
<BR>
|
||
SANE_Status status;
|
||
<BR>
|
||
int retries;
|
||
<BR>
|
||
|
||
<BR>
|
||
DBG (DL_CALL_TRACE, "%s\n", me);
|
||
<BR>
|
||
<P> for (retries = 5; retries; retries--)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
status = test_unit_ready (pss);
|
||
<BR>
|
||
if (status == SANE_STATUS_GOOD)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
status = request_sense (pss);
|
||
<BR>
|
||
switch (status)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
case SANE_STATUS_GOOD:
|
||
<BR>
|
||
return status;
|
||
<BR>
|
||
case SANE_STATUS_DEVICE_BUSY:
|
||
<BR>
|
||
/* first additional sense byte contains time to wait */
|
||
<BR>
|
||
{
|
||
<BR>
|
||
int delay = pss->asi1 + 1;
|
||
<BR>
|
||
DBG (DL_INFO,
|
||
<BR>
|
||
"%s: scanner warming up. Waiting %ld
|
||
<BR>
|
||
seconds.\n",
|
||
<BR>
|
||
me,
|
||
<BR>
|
||
(long) delay);
|
||
<BR>
|
||
sleep (delay);
|
||
<BR>
|
||
}
|
||
<BR>
|
||
break;
|
||
<BR>
|
||
case SANE_STATUS_IO_ERROR:
|
||
<BR>
|
||
/* hardware error; bail */
|
||
<BR>
|
||
DBG (DL_MAJOR_ERROR, "%s: hardware error detected.\n",
|
||
<BR>
|
||
me);
|
||
<BR>
|
||
return status;
|
||
<BR>
|
||
default:
|
||
<BR>
|
||
DBG (DL_MAJOR_ERROR,
|
||
<BR>
|
||
"%s: unhandled request_sense result; trying
|
||
<BR>
|
||
again.\n",
|
||
<BR>
|
||
me);
|
||
<BR>
|
||
break;
|
||
<BR>
|
||
}
|
||
<BR>
|
||
}
|
||
<BR>
|
||
}
|
||
<BR>
|
||
return status;
|
||
<BR>
|
||
}
|
||
<BR>
|
||
<P>So the basic logic is: if TEST UNIT READY fails, return an error; if
|
||
<BR>
|
||
TEST UNIT READY succeeds, issue REQUEST SENSE to read the warm up time
|
||
<BR>
|
||
(this time is stored at offset 18 in the sense buffer; this value is
|
||
<BR>
|
||
copied into pss->asi1 in the function request_sense). If REQUEST SENSE
|
||
<BR>
|
||
returns DEVICE BUSY, sleep for pss->asi1 seconds.
|
||
<BR>
|
||
<P>With the borrowed 1236, this does not seem to work.
|
||
<BR>
|
||
<P>If I run "scanimage -d snapscan:/dev/sg2" immediately after powering up
|
||
<BR>
|
||
the scanner, the program bails out without starting a scan. The debug
|
||
<BR>
|
||
message "scanner warming up" does not appear. The reason is, that TEST
|
||
<BR>
|
||
UNIT READY returns "busy" for at least 10 seconds after power up, so
|
||
<BR>
|
||
that the "if (status == SANE_STATUS_GOOD)" section is never run. A few
|
||
<BR>
|
||
seconds later, scanimage runs without any errors.
|
||
<BR>
|
||
<P>So I tried the following version of wait_scanner_ready:
|
||
<BR>
|
||
<P>static SANE_Status wait_scanner_ready (SnapScan_Scanner *pss)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
static char me[] = "wait_scanner_ready";
|
||
<BR>
|
||
SANE_Status status;
|
||
<BR>
|
||
int retries;
|
||
<BR>
|
||
|
||
<BR>
|
||
DBG (DL_CALL_TRACE, "%s\n", me);
|
||
<BR>
|
||
<P> for (retries = 20; retries; retries--)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
status = test_unit_ready(pss);
|
||
<BR>
|
||
if (status == SANE_STATUS_DEVICE_BUSY)
|
||
<BR>
|
||
{
|
||
<BR>
|
||
DBG(DL_INFO, "wait_scanner: sleeping (%i)...\n",
|
||
<BR>
|
||
retries);
|
||
<BR>
|
||
sleep(1);
|
||
<BR>
|
||
}
|
||
<BR>
|
||
else
|
||
<BR>
|
||
return status;
|
||
<BR>
|
||
}
|
||
<BR>
|
||
return status;
|
||
<BR>
|
||
}
|
||
<BR>
|
||
<P><P>This version of wait_scanner_ready works better than the "official" one:
|
||
<BR>
|
||
After powering up the scanner, the "for (retries..." loop is executed 12
|
||
<BR>
|
||
or 13 times; later, TEST UNIT READY succeeds immediately. And it avoids
|
||
<BR>
|
||
the explicit issueing of REQUEST SENSE.
|
||
<BR>
|
||
<P>If have no access to other scanners supported by the Snapscan backend
|
||
<BR>
|
||
(and to the 1236 only for a limited time), neither do I have access to
|
||
<BR>
|
||
any documentation for these scanner, so I can't tell, if the original
|
||
<BR>
|
||
logic of wait_scanner_ready is reasonable for other scanner.
|
||
<BR>
|
||
<P>But if the current "official" version of wait_scanner_ready is simply
|
||
<BR>
|
||
based on a misunderstanding of the REQUEST SENSE logic in a multitasking
|
||
<BR>
|
||
OS (and the fact, that the Snapscan obviously stores the expected warm
|
||
<BR>
|
||
up/power up time at offest 18 in the sense buffer, which is difficult to
|
||
<BR>
|
||
access, if only 18 or 16 sense buffer bytes are returned), it might be
|
||
<BR>
|
||
reasonble, if the Snapscan maintainers improve the current version. This
|
||
<BR>
|
||
might not only solve headaches for people using the Snapscan backend
|
||
<BR>
|
||
under Linux -- I don't know, how the other OS supported by Sane will
|
||
<BR>
|
||
respond to a REQUEST SENSE command issued from usert space.
|
||
<BR>
|
||
<P>Abel
|
||
<BR>
|
||
<P>PS: J<>rgen, sorry for causing perhaps unnecessary work...
|
||
<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:%20Problem%20with%20kernel%202.4ac9,%20ava1505,%20snapscan1236s,%20sane1.0.4&In-Reply-To=<3A648C1E.38EE1C42@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
||
</PRE>
|
||
<P><!-- body="end" -->
|
||
<HR NOSHADE>
|
||
<UL>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0154.html">Joern Clausen: "Nikon LS-2000 with Solaris"</A>
|
||
<LI><STRONG>In reply to:</STRONG> <A HREF="0143.html">Douglas Gilbert: "Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0156.html">Oliver Rauch: "REQUEST_SENSE calls by backends"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0158.html">Henning Meier-Geinitz: "Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#155">[ date ]</A>
|
||
<A HREF="index.html#155">[ thread ]</A>
|
||
<A HREF="subject.html#155">[ subject ]</A>
|
||
<A HREF="author.html#155">[ 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>Tue Jan 16 2001 - 08:52:55 PST</EM>
|
||
</EM>
|
||
</SMALL>
|
||
</BODY>
|
||
</HTML>
|