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
