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