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

abel deuring a.deuring@satzbau-gmbh.de
Sun, 28 Oct 2001 20:43:07 +0100

Henning Meier-Geinitz wrote:
> Hi,
> On Sun, Oct 28, 2001 at 02:18:09PM +0100, abel deuring wrote:
> > 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,
> > Linux.
> I think that's ok. Backends who want to catch BUSY can do so and the
> others will fail as before. An alternative would be to resend the
> command inside sanei_scsi but I don't know if this makes much sense.


Doing this inside sanei_scsi might cause quite a mess, if command
queueing is used. Assume that the commands SET WINDOW and GET WINDOW are
queued. The result of GET WINDOW depends on the execution of SET WINDOW,
so re-issuing a failing SET WINDOW after GET WINDOW has been sent is
simply confusing. The backends can better handle such a situation.

> > >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[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...)
> I think one minute should be enough but you never know...
> In my opinion, both items are for SANE 1.0.7, not for the upcoming
> 1.0.6 release. I will add a TODO entry. Maybe someone can also look at
> the Linux/sparc SCSI access problems mentioned in TODO. Or is this
> already fixed?

Right, that's all stuff for 1.0.7.