SCSI scanner problem with all kernels since 2.3.42

SCSI scanner problem with all kernels since 2.3.42

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

I'm having problems with using xsane to acquire a preview from an HP
ScanJet 5P connected to an AHA-2940.  2.3.42 is the last kernel that
works right for me.

The symptom is that the scanner starts to make scanning sounds, then
stops, and xsane says 'Error during read: Error during device I/O'.

Any ideas?

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: SCSI scanner problem with all kernels since 2.3.42

[Douglas Gilbert]

Tim Waugh wrote:
> I'm having problems with using xsane to acquire a preview from an HP
> ScanJet 5P connected to an AHA-2940.  2.3.42 is the last kernel that
> works right for me.
> 
> The symptom is that the scanner starts to make scanning sounds, then
> stops, and xsane says 'Error during read: Error during device I/O'.

Tim and I have been looking at this offline. The significance
of lk 2.3.43 was the addition of a new sg driver that has an
additional interface. Recent versions of SANE use that newer
sg interface. The problem that Tim reported seemed to be caused
by timeouts ** resulting in scsi bus resets. Anyway the problem
seems to disappear with the recently released SANE 1.0.4 .
[The original report was based on SANE 1.0.3 and earlier.]

There is also a problem report with the  SnapScan 1236 <--> aha152x 
combination also based on SANE 1.0.3 . This one is looking 
like an "uninitialized errno" bug fixed in SANE 1.0.4 .

** SANE's newer sg interface shortens the per command timeout
from 10 minutes to 10 seconds. Most other OSes interfaces in
SANE have a timeout value of 1 minute or more. I suspect 10 
seconds may be too short.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanner problem with all kernels since 2.3.42

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Tue, Jan 09, 2001 at 03:53:02PM -0500, Douglas Gilbert wrote:

> by timeouts ** resulting in scsi bus resets. Anyway the problem
> seems to disappear with the recently released SANE 1.0.4 .
> [The original report was based on SANE 1.0.3 and earlier.]

In fact my report that the problem went away was wrong. :-(

> ** SANE's newer sg interface shortens the per command timeout
> from 10 minutes to 10 seconds. Most other OSes interfaces in
> SANE have a timeout value of 1 minute or more. I suspect 10 
> seconds may be too short.

Increasing the timeout fixed the problem.

Thanks,
Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: SCSI scanner problem with all kernels since 2.3.42

[Juergen E Fischer]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

Hi Doug,

On Tue, Jan 09, 2001 at 03:53:02PM -0500, Douglas Gilbert wrote:
> There is also a problem report with the  SnapScan 1236 <--> aha152x 
> combination also based on SANE 1.0.3 . This one is looking 
> like an "uninitialized errno" bug fixed in SANE 1.0.4 .

This should be solved with the attached patch.   As you might remember
it's the same problem we already discussed with Abel Deuring.

Normally there should be no need to use REQUEST SENSE from outside,
when the driver supports auto-sense. It should be wrong as devices are
required to clear the sense data after the first, automatically issued
REQUEST SENSE.  BTW the new eh code requires low-level drivers to do
auto-sense.  The driver assumed that these are wrong and ignores them.
This behaviour was adopted from the aha1542 driver.

But for the SnapScan REQUEST SENSE is not only used on CHECK CONDITION,
but also to request the warmup time.  Therefore the REQUEST SENSE is
valid here and proves the assumption wrong for such devices.

Even more worse is that the driver returned SUCCESS instead of 0 on
REQUEST SENSE.  That's plain wrong and apparently tells the mid-level
code not to queue any more commands.

The warmup time issue with the SnapScan (and maybe other devices) should
also apply to the aha1542 driver.


Juergen

-- 
Juergen E Fischer


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: aha152x.diff --]
[-- Type: text/plain; charset=us-ascii, Size: 3161 bytes --]

diff -ur orig/linux/drivers/scsi/aha152x.c linux/drivers/scsi/aha152x.c
--- orig/linux/drivers/scsi/aha152x.c	Fri Dec 29 23:35:47 2000
+++ linux/drivers/scsi/aha152x.c	Sun Jan 14 21:31:12 2001
@@ -1,6 +1,6 @@
 /* aha152x.c -- Adaptec AHA-152x driver
  * Author: Jürgen E. Fischer, fischer@norbit.de
- * Copyright 1993-1999 Jürgen E. Fischer
+ * Copyright 1993-2000 Jürgen E. Fischer
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -13,9 +13,13 @@
  * General Public License for more details.
  *
  *
- * $Id: aha152x.c,v 2.3 2000/11/04 16:40:26 fischer Exp $
+ * $Id: aha152x.c,v 2.4 2000/12/16 12:53:56 fischer Exp $
  *
  * $Log: aha152x.c,v $
+ * Revision 2.4  2000/12/16 12:53:56  fischer
+ * - allow REQUEST SENSE to be queued
+ * - handle shared PCI interrupts
+ *
  * Revision 2.3  2000/11/04 16:40:26  fischer
  * - handle data overruns
  * - extend timeout for data phases
@@ -932,6 +936,8 @@
         	printk(KERN_ERR "aha152x%d: catched software interrupt for unknown controller.\n", HOSTNO);
 
 	HOSTDATA(shpnt)->swint++;
+
+	SETPORT(DMACNTRL0, INTEN);
 }
 
 
@@ -1274,7 +1280,7 @@
 		SETPORT(SIMODE0, 0);
 		SETPORT(SIMODE1, 0);
 
-		ok = request_irq(shpnt->irq, swintr, SA_INTERRUPT, "aha152x", shpnt);
+		ok = request_irq(shpnt->irq, swintr, SA_INTERRUPT|SA_SHIRQ, "aha152x", shpnt);
 		if (ok < 0) {
 			if (ok==-EINVAL)
 				printk(KERN_ERR "aha152x%d: bad IRQ %d.\n", HOSTNO, shpnt->irq);
@@ -1308,6 +1314,8 @@
 				printk("failed.\n");
 			}
 
+			SETPORT(DMACNTRL0, INTEN);
+
 			printk(KERN_ERR "aha152x%d: IRQ %d possibly wrong.  Please verify.\n", HOSTNO, shpnt->irq);
 
 			registered_count--;
@@ -1319,13 +1327,12 @@
 		}
 		printk("ok.\n");
 
-		SETPORT(DMACNTRL0, INTEN);
 
 		/* clear interrupts */
 		SETPORT(SSTAT0, 0x7f);
 		SETPORT(SSTAT1, 0xef);
 
-		if (request_irq(shpnt->irq, intr, SA_INTERRUPT, "aha152x", shpnt) < 0) {
+		if (request_irq(shpnt->irq, intr, SA_INTERRUPT|SA_SHIRQ, "aha152x", shpnt) < 0) {
 			printk(KERN_ERR "aha152x%d: failed to reassign interrupt.\n", HOSTNO);
 
 			scsi_unregister(shpnt);
@@ -1469,12 +1476,14 @@
 
 int aha152x_queue(Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
 {
+#if 0
 	if(*SCpnt->cmnd == REQUEST_SENSE) {
 		SCpnt->result = 0;
 		done(SCpnt);
 
-		return SUCCESS;
+		return 0;
 	}
+#endif
 
 	return aha152x_internal_queue(SCpnt, 0, 0, 0, done);
 }
diff -ur orig/linux/drivers/scsi/aha152x.h linux/drivers/scsi/aha152x.h
--- orig/linux/drivers/scsi/aha152x.h	Mon Dec 11 22:19:02 2000
+++ linux/drivers/scsi/aha152x.h	Fri Jan 12 13:18:24 2001
@@ -2,7 +2,7 @@
 #define _AHA152X_H
 
 /*
- * $Id: aha152x.h,v 2.3 2000/11/04 16:41:37 fischer Exp $
+ * $Id: aha152x.h,v 2.4 2000/12/16 12:48:48 fischer Exp $
  */
 
 #if defined(__KERNEL__)
@@ -27,7 +27,7 @@
    (unless we support more than 1 cmd_per_lun this should do) */
 #define AHA152X_MAXQUEUE 7
 
-#define AHA152X_REVID "Adaptec 152x SCSI driver; $Revision: 2.3 $"
+#define AHA152X_REVID "Adaptec 152x SCSI driver; $Revision: 2.4 $"
 
 /* Initial value of Scsi_Host entry */
 #define AHA152X { proc_name:			"aha152x",		\