[sane-devel] linux 2.4 scsi problems, sane 1.0.5
Sun, 28 Oct 2001 14:18:09 +0100
Henning Meier-Geinitz wrote:
> On Sat, Oct 27, 2001 at 10:27:01PM -0700, email@example.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? 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
From a more general viewpoint, I wonder, if we should specify the
behaviour of sanei_scsi_req_enter, sanei_scsi_req_wait and
sanei_scsi_cmd 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...)