I just built the SANE-0.71 release, with the latest version of the backend,
actually (which I just mailed to David M-T.), and I am getting the following
debugging chunk:
[microtek] .start_scan...
[microtek] .wait_ready 5...
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (0)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (1)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (2)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (3)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (4)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (5)
[microtek] sense: ERR_SCSICMD[microtek] wait_ready failed (6)
[microtek] sane_cancel...
This looks like it is a result of changes made to the Linux portion of
sanei/sanei_scsi.c regarding checking of return codes. Here is the diff
that worries me: (< is 0.71, > is 0.70)
729,730c674
< if (req->cdb.hdr.result == 0
< && (req->cdb.hdr.sense_buffer[0] & 0x7f) == 0)
--- > if (req->cdb.hdr.result == 0) 744c688,689 < void *arg = fd_info[req->fd].sense_handler_arg;--- > void *arg > = fd_info[req->fd].sense_handler_arg; 751c696 < else if (handler)--- > else if ((req->cdb.hdr.sense_buffer[0] & 0x80) && handler)
If I remove the "&& (req->cdb.hdr.sense_buffer[0] & 0x7f) == 0" clause and recompile, everything works A-OK.
The ChangeLog states:
* sanei/sanei_scsi.c (sanei_scsi_req_wait) [USE == LINUX_INTERFACE]: Always check for a non-zero error code in the sense-buffer. The Linux sg driver guarantees that the sense buffer is clear to zero when no sense code has been requested, so this is safe.
I don't really know what is going on, but it looks to me like the sg driver made some promises it doesn't keep.
For the record: Microtek E6, AVA-1502AE scsi card, 2.0.32 kernel, Debian w/libc6 dev. env. and sane 0.70 worked just fine for me.
(Who knows, I bet the aha152x driver is the culprit....)
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com