[sane-devel] Sane, Microtek ScanMaker II and Mac OS X SCSI
m. allan noah
Fri, 5 Mar 2004 15:44:07 -0500 (EST)
i replied to this earlier, and suggested that you see if you can turn off
the 'probe multiple luns' option in the bios of your scsi adapter or the
driver for it in your os. i know nothing about macs, however.
On Fri, 5 Mar 2004, David B Brown wrote:
> what's the "multiple LUN" problem ? The scanner is responding 8 times
> to the Inquiry request, each time with a different LUN. I had a hunch
> this might be confusing the scanner, but it looks like the Mac OS X
> implementation in sanei_scsi.c searches for scanners by vendor and
> model only, when the microtek backend attaches to the scanner it
> attached to the last one that responded to the Inquiry command which is
> always LUN 07.
> After the start scan, then scanner does start moving, not actually
> scanning, but all the pre-scam noises and movements that are normal for
> this scanner but then within 20-30 seconds it seems to reset itself.
> On 4 Mar 2004, at 20:41, Matto Marjanovic wrote:
> > ...
> >> So the first thing that fails is the first scsi command being sent
> >> that
> >> has the isWrite set to 0:
> >> [microtek] .get_scan_status 0...
> >> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:6 isWrite:0
> >> [sanei_scsi] isRead dst_size:6
> >> [sanei_scsi] Executing command
> >> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
> >> [microtek] get_scan_status(0): 0, 0, 0 -> #0
> >> I would understand this better if this was a "read only" problem, but
> >> this seems to be a "write only" problem, which doesn't make sense...
> > Has that "Multiple LUN" problem been ruled out yet? Perhaps the
> > scanner
> > is responding for some commands, but not for others.
> > Another possible odd-ball issue is that this set of Microtek scanners
> > does
> > not use a SCSI-2 command set --- it's a variant of SCSI-1 with a lot
> > of
> > vendor-defined commands and completely non-standard sense codes.
> > Perhaps
> > the OS-X iokit is getting confused by that. (The linux scsi drivers
> > have
> > pretty much never returned the sense codes back to user-space without
> > mangling them beyond recognition.)
> > Another question: does the scanner ever start moving/making noises?
> > The log snippets show that "start_scan" is received ok --- the scanner
> > should start doing something after that. If not, maybe "start_scan"
> > has not been received ok.
> > Hmm...
> > Quite possibly *none* of the commands (besides INQUIRY) have been
> > received ok --- but the sense codes are being ignored, and the
> > get_scan_status is the first command that is actually waiting for
> > data to return from the scanner, hence the first one that hangs.
> > -matt m.
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera