>> What does the patch do? (And how did it fix up the Microtek scanning?) ... >depending on the status returned by the OS. The sense handler is only >called, if ccb->ccb_h.status & CAM_AUTOSNS_VALID is true, which should >guarantee that useful sense data is available. ... >Without the patch, the sense handler of backend is called for every >failing command, but because no sense data is available, the sense >handler decides to return SANE_STATUS_GOOD, hence the backend makes >wrong assuptions about the status of the scanner. > >What I don't really understand in hindsight is the CAM status value 16 >in Martin's log data. It indicates that the FreeBSD CAM system tried to >issue a REQUEST SENSE for one or another failing command (where >"failing" means in this case that the scanner accepted the command, and >returned CHECK CONDITION), and that the REQUEST SENSE was not >successful.
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. 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. It's just a theory... (I've never tried nor read FreeBSD code), -matt m.
