[sane-devel] linux 2.4 scsi problems, sane 1.0.5

abel deuring a.deuring@satzbau-gmbh.de
Sun, 28 Oct 2001 14:18:09 +0100


Henning Meier-Geinitz wrote:
> 
> Hi,
> 
> On Sat, Oct 27, 2001 at 10:27:01PM -0700, eric-sane@limpoc.com wrote:
> > I've recently come back to trying to make a Sharp JX-610 SCSI scanner work
> > under Linux 2.4.9. I had no trouble under earlier 2.2 kernels but unfortunately
> > running those is no longer an option for me.
> > The SCSI adapter is an Adaptec 7896 using the aic7xxx driver.
> 
> [...]
> 
> > I imagine this must be a problem for many people, as it seems to me that anyone
> > using Linux 2.4 and an adaptec scsi adapter (at least) must be experiencing
> > it.
> 
> I'm using an Adaptec 2940 with the aic7xxx driver without any problems
> (Linux 2.4.9, 2.4.13).
> 
> If I remember correctly, some people has success using the old aic7xxx
> driver (aic7xxx_old) instead of the new one. It's also included in the
> standard kernels.
> 
> If this also happens with current kernels (2.4.13), please write also
> to the developers of the kernel driver.

Henning,

I agree that the new aic7xxx driver might be involved in Eric's problem,
but I don't think that the driver should be blamed.

Eric's debug output show that a READ command fails with the status code
DEVICE BUSY. The Sharp backend uses command queueing, so it could be
that the new aic7xxx driver has a shorter delay between completing a
command and starting the next command. So the second command might be
sent at a time, when the scanner does not accept a READ command.

Looking through sanei_scsi.c, I discovered that sanei_scsi_req_wait (for
Linux) does not return SANE_STATUS_DEVICE_BUSY for the SCSI status
DEVICE BUSY, so it is difficult for the backend to decide what to do if
a command fails. Interestingly, the implementations of
sanei_scsi_req_wait resp. sanei_scsi_cmd2 for a number of other OSes
have the same problem, for example HPUX, Openstep, DEC Unix, Aix.

If my guess about Eric's problem is correct, I'll need to fix the Sharp
backend -- but the question is, what to do with the result codes of
sanei_scsi_req_wait and sanei_scsi_cmd[2]? A clean solution in the
backend would be to retry a READ command, if sanei_scsi_req_wait returns
SANE_STATUS_DEVICE_BUSY, and to return an error for
SANE_STATUS_IO_ERROR. But at present, this would only work with the
sanei_scsi.c parts for BSD_INTERFACE, FREEBSD_CAM_INTERFACE,
SOLARIS_INTERFACE and SOLARIS_USCSI_INTERFACE, and (with a patch) for
Linux. 

From a more general viewpoint, I wonder, if we should specify the
Status: O

behaviour of sanei_scsi_req_enter, sanei_scsi_req_wait and
sanei_scsi_cmd[2] more precisely. Another example is the timeout value
for SCSI commands; for most OSes, this value is 1 minute, except for
Linux, where it is 10 minutes (except for my mess with the SG3 interface
in Sanei 1.0.3 and 1.0.4, where the timeout was only 10 seconds...)

Any comments?

Abel