Erik Inge Bolsų wrote:
>
> On Sun, 14 Jan 2001, Douglas Gilbert wrote:
> >> [snapscan] request_sense
> >> [snapscan] sense_handler(5, 0xbffff324, 0x8050c90)
> >> [snapscan] sense_handler: sense key is invalid.
>
> The problem was here. The aha152x.c driver filtered out request_sense
> commands and always returned 0 on them. (At least that's my layman's
> understanding of the problem.)
>
> int aha152x_queue(Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
> {
> if(*SCpnt->cmnd == REQUEST_SENSE) {
> SCpnt->result = 0;
> done(SCpnt);
>
> return SUCCESS;
> }
>
> return aha152x_internal_queue(SCpnt, 0, 0, 0, done);
> }
>
> Removing everything but the "return" line fixed the problem :)
>
> Thanks to Marcel Martin for the fix :)
This is interesting. The linux scsi subsystem (as does
FreeBSD's CAM) implements "autosense" to get its sense
buffer after a command has failed. This means that when
a command like "test unit ready" is sent and it returns
a "check condition" status code then the subsystem will
automatically issue a "request sense" and give its
response back as the sense buffer of the original command
("test unit ready" in this case).
So SANE backends shouldn't be issuing "request sense"
commands IMHO. BTW only the first "request sense" gets
the error response, so sending more of them is useless.
It seems as though a problem that Arnold Schiller has
sent me is very similar: a SnapScan1236/aha152x
combination that locks up just after a "request sense"
is sent to the scanner.
Anyway, the aha152x driver probably shouldn't be reacting
the way it is.
Doug Gilbert
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sun Jan 14 2001 - 11:13:05 PST