Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4

From: Douglas Gilbert (
Date: Sun Jan 14 2001 - 11:34:49 PST

  • Next message: Erik Inge Bolsų: "Re: Problem with kernel 2.4ac9, ava1505, snapscan1236s, sane1.0.4"

    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:
    To unsubscribe: echo unsubscribe sane-devel | mail

    This archive was generated by hypermail 2b29 : Sun Jan 14 2001 - 11:13:05 PST