SCSI scanner problem with all kernels since 2.3.42
Subsystems (2)
Quoted 6 lines · Tim Waugh
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Douglas Gilbert
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. :-(
Quoted 4 lines
** 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.
*/
Hi Doug,
Quoted 3 lines · Douglas Gilbert
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
Signature · 1 line
Juergen E Fischer
drivers/scsi/aha152x.c renamed from linux/drivers/scsi/aha152x.c +15 -6
@@ -1,6 +1,6 @@/* aha152x.c -- Adaptec AHA-152x driver * Author: Jürgen E. Fischer, [email protected] -* 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); }
drivers/scsi/aha152x.h renamed from linux/drivers/scsi/aha152x.h +2 -2
@@ -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", \