[sane-devel] Sane, Microtek ScanMaker II and Mac OS X SCSI

[David B Brown]

Allan,


	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.


	Cheers


David


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 
> 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.
>
> allan
>
> On Fri, 5 Mar 2004, David B Brown wrote:
>
>> Matto,
>>
>>
>>   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.
>>
>>
>>
>> Cheers
>>
>> David
>>
>>
>>
>> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20040305/50c9ec7a/attachment.sig>