Re: Problem with SANE and SCSI scanner

Douglas Gilbert (dgilbert@interlog.com)
Thu, 02 Dec 1999 22:10:28 -0500

Manuel Panea wrote:
>
> [snip]
> > The failure (EIO) on the sg device handle (4 in this case)
> > indicates the buffer passed to sg's write() was too small.
> > A length of 42 implies a maximum SCSI command length of 6
> > bytes (because the accompanying sg_header structure is 36
> > bytes long). Digging around the canon backend code in
> > sane-1.0.1, it seems to be sending an opcode of 0xd5
> > for "GET SCAN MODE". Such an opcode can only be 10 bytes
> > long (12 bytes if another flag was set but I can see above
> > it is not).
> >
> > Doug Gilbert
> > Linux sg maintainer
>
> Aha! So *you* are the sg maintainer. If you have read my last answer to
> Laura, you know that you are right: sg and sane get confused about the
> SCSI command sizes.

The maintainers of various parts of the Linux kernel
and associated drivers are listed in
/usr/src/linux/MAINTAINERS . The maintainers are asked to
monitor relevant newsgroups and let it be known once
in a while. There may well be maintainers of other free OSes
also monitoring this group.

> Now why is this so? I was (fortunately) told about this problem by a canon
> backend user who described it as a bug in sg, but now you talk as if it
> were sane's fault. So is it sg's fault or is it sane's fault? (I don't
> think it can be the backend's fault, all I do is try to send the scanner a
> perfectly valid SCSI command.) What should be changed to not have to tell
> the users to "go patch /usr/src/linux/drivers/scsi/sg.c"?

Manuel,

The Linux sg driver has been around since 1992 with its
awkward "sg_header" based interface. It makes many
assumptions, one of which is that SCSI commands with
opcodes >= 0xc0 can only be 10 or 12 bytes long. Obviously
this is why the Canon driver needs or needed that patch.

Things are gradually being improved. From and including
lk 2.2.10 there is an ioctl() in sg called SG_NEXT_CMD_LEN
that sets the length of the next SCSI command. That solves
your immediate problem. The sg version number can be found
with the ioctl() SG_GET_VERSION_NUM. There is an additional
interface structure called sg_io_hdr that is being added
to the sg driver in the linux 2.3 development tree. Abel
Deuring <a.deuring@satzbau-gmbh.de> has developed a Mustek
backend using it. More information about sg can be found
at http://www.torque.net/sg .

Returning to Laura's strace output from yesterday. The
strace output indicated that a write() called failed
with an EIO error yet the Sane error message was:
"open of device canon:/dev/sga failed: Invalid argument".
With accurate error information and a document like
/usr/src/linux/Documentation/scsi-generic.txt perhaps
this problem could have been diagnosed earlier.

Doug Gilbert

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com