[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.


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

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?