[sane-devel] Sane, Microtek ScanMaker II and Mac OS X SCSI
David B Brown
Fri, 5 Mar 2004 20:53:00 +0000
Content-Type: text/plain; charset=US-ASCII; format=flowed
sorry must have missed that one.
I've no idea how to do that, or even if it's possible in Mac OS X or
with the Adaptec 2906. Anyone got and ideas?
This as however why I was looking at the way the code inquires,
searches for and attaches to the scanner, I was hoping to specify a LUN
in the microtek.conf file, but as I mentioned below, the code only
seems to use vendor and model.
BTW before anyone asks I have this exact setup booting into OS9, and
it works. I do know there was lots of talk of the SCSI implementation
in OS X being more strict, but my view is fundamentally the hardware
side is ok, this issues is a software one.
On 5 Mar 2004, at 20:44, m. allan noah wrote:
> i replied to this earlier, and suggested that you see if you can turn
> the 'probe multiple luns' option in the bios of your scsi adapter or
> 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
>> 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
>> 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
>> 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
>>>> 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,
>>>> this seems to be a "write only" problem, which doesn't make sense...
>>> Has that "Multiple LUN" problem been ruled out yet? Perhaps the
>>> is responding for some commands, but not for others.
>>> Another possible odd-ball issue is that this set of Microtek scanners
>>> not use a SCSI-2 command set --- it's a variant of SCSI-1 with a lot
>>> vendor-defined commands and completely non-standard sense codes.
>>> the OS-X iokit is getting confused by that. (The linux scsi drivers
>>> pretty much never returned the sense codes back to user-space
>>> 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
>>> should start doing something after that. If not, maybe "start_scan"
>>> has not been received ok.
>>> 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
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----