[sane-devel] FreeBSD and Microtek Scanmaker II

abel deuring a.deuring@satzbau-gmbh.de
Sat, 21 Jun 2003 16:31:27 +0200


Matto Marjanovic wrote:

> A-ha --- ok, the sense handler is not called, an error condition is returned,
>  and then - I imagine - the retry logic in the backend takes over.

Right, I think that's happening.

> 
> With regards to the mystery status value:  in this situation under Linux
>  (i.e., the scanner is busy, won't accept next command), a REQUEST SENSE
>  *is* issued and the scanner *does* respond to it.  However, the returned
>  data does not conform to SCSI-2.  In particular, the bit defined by
>  Microtek to mean "this is valid sense data" is the bit which, in SCSI-2,
>  means "this is *not* valid sense data".
> Because of this, the mid-level Linux SCSI driver *zeros out* the sense data,
>  yet still indicates that REQUEST SENSE has been issued.  Thus the backend's
>  sense handler is called with absolutely nothing and decides "No error".
> 
> I suspect a similar thing is happening in the FreeBSD CAM system --- some
>  midlevel driver is unnecessarily killing the sense data.  Your patch checks
>  to see if the system thought the sense data is/was valid, and since it was
>  declared invalid, issues a general error instead.


Matt,

are you sure that the Linux SCSI system (or FreeBSD) tries to issue a
REQUEST SENSE, if it can't "connect" to device? (If I find enough time,
I'll try that at home today or tomorrow. Shouldn't be difficult to
provoke such a situation with my Sharp JX250. Removing the O_EXCL flag
on the open call for the device file, using huge data blocks for READ
commands and then attepting to access the scanner form a different
process are worth a try.) OK, a SCSI device should be able to respond to
a few basic commands like INQUIRY or REQUEST SENSE under more or less
any circumstances, but the main point of the error "can't issue a SCSI
command, because the device is busy" is to try it again later. I don't
see the point, which additional information a REQUEST SENSE would
provide.

It's another point, if a command has been accepted by the device. If
this command results in an error, a REQUEST SENSE if of course useful.

Abel