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

[abel deuring]

Henning Meier-Geinitz wrote:
> 
> Hi,
> 
> On Sat, Oct 27, 2001 at 10:27:01PM -0700, eric-sane at 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.