[sane-devel] FreeBSD and Microtek Scanmaker II

abel deuring a.deuring@satzbau-gmbh.de
Wed, 18 Jun 2003 13:49:28 +0200

Nakal wrote:
> On Tuesday 17 June 2003 23:30, abel deuring wrote:
> > First a disclaimer for the following stuff: I don't have FreeBSD
> > installed, I used it only rarely, and I never wrote software
> > specifically for FreeBSD. So I am writing as a "backseat driver" ;)
> <flame-protection>
> Try it :)
> </flame-protection>

if you can give me some time ;)

> > 10 -> CAM_SEL_TIMEOUT,        /* Target Selection Timeout */
> > 16 -> CAM_AUTOSENSE_FAIL = 0x10,/* Autosense: request sense cmd fail
> > */
> > (definitions of this kind tend to be stable -- but control is better
> > than trust some cases: Martin, can you confirm this for your version
> > of cam.h?)
> The values 10 and 16 are still correct, but I'm sure you are using the
> enums by name. That should be fine, of course. Seems nothing has
> changed in cam.h since 2000/03/17. Even FreeBSD-current (5.1) seems to
> use the same values (2002/01/09).

I tried to identify the error numbers in the log file.

> You can find the kernel sources for cam here (just in case you haven't
> found cam.c):
> ftp://ftp2.freebsd.org/pub/FreeBSD/FreeBSD-stable/src/sys/cam

Thanks for the pointer. But I think that it should be sufficient to read
the CAM documentation on the FressBSD web site ;) It looks quite

> > OK, many commands fail with a selection time out. Not very surprising
> > for a slow scanner with probably somewhat dumb firmware ;)
> Firmware? :) No firmware patch yet. My scanner is still good :) I'm
> patient.

An update should not be necessary (and would ptobably not help very
much). What I meant is this: The first failing command ("stop scan") is
rejected by the scanner with the reason "I'm busy". I assume that this
is caused by a firmware which completely occipied by controlling the
stepper motor of the scan head to move the scan head back after the
scan. A better firmware with a decent interrupt management is able to
accept SCSI command in such a situation, But Sane (specifically,
sanei_scsi.c and the backend) should be able to work with a dumb

> > Another point: From reading cam.h, I think that the sense handler
> > should only be called, if the bit CAM_AUTOSNS_VALID is set in
> > ccb_h.status.
> Hmmm... that's too high-level for me. I am not really a kernel
> developer. Maybe freebsd mailing lists would help you.
> http://www.freebsd.org/support.html#mailing-list

Thanks for the hint, but again, it should not be necesary to bother the
FreeBSD developers. When a SCSI command is accepted by a device but
results in an error, some details of the error are described in the
so-called sense data, which can be retrieved by another SCSI command
(REQUEST SENSE). REQUEST SENSE is automatically issued by the operating
system, if this is reasonable. When the call issueing the failing
command ends, the application can (1) check, if sense data is available,
and (2) do some "clean up" or print details error information (for
scanners, this can be tinhgs like "12V fuse blown" of "mechanical
error", but also more generic stuff like "invalid SCSI command
parameter"). One problem of the CAM part of sanei_scsi.c is that the
avaliability of the sense data is not checked -- it simply assumes that
it is available..

> > Generally, I have the impression that the FreeBSD/CAM part of
> > sanei_scsi.c could need a review. But that should be done by somebody
> > who can run Sane under FreeBSD ;)
> Well, I will try to help, but I am also a simple user who just writes
> 'make install' in /usr/ports/graphics/xsane and is expecting that
> everything works after few minutes. :)
> Generally it is better to have contact with the responsible ports
> committer. You can find him here:
> http://www.FreeBSD.org/cgi/ports.cgi?query=xsane&stype=all
> The ports version of xsane in FreeBSD ports tree is 0.90. Tomorrow I
> want to take a look, if I am able to build xsane-0.90 with your
> suggested patch.

No need to (re-)build xsane; the problem is in sane-backends. And I'm
afraid that my patch will not completely fix it -- I think that there
will be the need to retry a SCSI command that returns with "device
busy". The problem is that I'm not sure, if this should be done in
sanei_scsi.c or in the backend. IIRC we had a discussion of this
question some time ago, but I don't have currently the time to search
for it... 

If we don't find a volunteer for fixing sanei_scsi.c, I'll give a try
during the weekend.