[sane-devel] Re: sane-devel digest, Vol 1 #317 - 6 msgs

[David Brown]

--Apple-Mail-1--291098809
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Abel,


	thanks for responding even if you're not a Mac OS X expert :-)

	See my comments below


>>
>> ISSUE: My coding is rusty and my knowledge of the SCSI API used for 
>> Mac OS X is worse, but I believe that the Mac OS X scsi code doesn't 
>> support specifying a LUN and SCSI ID in the microtek.conf file. From 
>> my testing if the code has to search for the scanners it only uses 
>> the vendor and device name, and ends up attached to the wrong LUN
>
> Right, from a quick look into the MacOS X part of sani_scsi.c, it 
> seems that from the two functions possibly called by 
> sanei_scsi_find_devices, only sanei_scsi_find_devices_old_api 
> "recognizes" the LUN, while sanei_scsi_find_devices_stuc_api ignores 
> any LUN specification. While it is essentially a bug of the scanner to 
> respond to INQUIRY commands on all LUNs, applications should be able 
> to deal with it.
>



I agree this is a Bug, however I checked the Max OS X developer notes 
on the Web, LUN is not listed as one of the values you can use to 
search the dictionary hence sanei_scsi_find_devices using vendor and 
model only. I guess we could re-code this to search by vendor and 
model, and then go through the found devices and match against bus, 
lun, etc




>>
>> [microtek] sane_start...
>> [microtek] sane_get_parameters...
>> [microtek] sane_get_parameters: regular 3-pass color
>> [microtek] sane_get_parameters: res_code = 33 (21)
>> [microtek] sane_get_parameters: dots_per_mm: 3.937008
>> [microtek] sane_get_parameters: units_per_mm: 11.811024
>> [microtek] WIDTHPIX: before exp: 850
>> [microtek] sane_get_parameters: lines: 1400 ppl: 850 bpl: 850
>> [microtek] set_pass_parameters: three-pass, on 2
>> [sanei_debug] Setting debug level of sanei_scsi to 6.
>> [microtek] .wait_ready 0...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:0
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] finagle_precal...
>> [microtek] .scanning_frame...
>> [microtek] .scanning_frame: in- 0,0 2549,4199
>> [microtek] .scanning_frame: out- 0,0 2549,4199
>> [sanei_scsi] cmd2: cmd_size:6 src_size:9 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:9
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] .accessory...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:0
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] .download_gamma...
>> [microtek] .download_gamma: 256 entries of 1 bytes, max 255
>> [microtek] .download_gamma: by default
>> [sanei_scsi] cmd2: cmd_size:10 src_size:256 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:256
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] .mode_select 0...
>> [microtek] .mode_select: pap_len: 4199
>> [sanei_scsi] cmd2: cmd_size:6 src_size:10 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:10
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] .wait_ready 0...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:0
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [microtek] .start_scan...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:0
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> [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
>> [microtek] > 0 0 0 0 0 0
>> [microtek] sane_start: SCSI buffer smaller that one scan line!
>
> strange. The SCSI buffer size is 128 kB for MacOS X, and the Scanmaker 
> II has a maximum resolution of 300 dpi, IIRC. Hence we have for a scan 
> width of 210mm at most 210*300/25.4=2480 pixel per line, and that's 
> far less than 128k. Perhaps the avlue of the variable 
> sanei_scsi_max_request_size is corrupted.


Yes the SCSI buffer is 128K for MacOS X, this is not specific to the 
Scanmaker II, but is general to the SCSI code. I put some extra debug 
comments in, re-ran the tests and it appears that this value is OK.


>
>> [microtek] end_scan...
>> [microtek] .stop_scan...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
>> [sanei_scsi] isWrite src_size:0
>> [sanei_scsi] Executing command
>> [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
>> scanimage: sane_start: Out of memory
>> [microtek] sane_cancel...
>> [microtek] end_scan...
>> [microtek] sane_close...
>> [microtek] sane_exit...
>> [microtek] sane_exit: MICROTEK says goodbye.
>> [MacCoylton:~] dave%
>> Scenario 2 :- If I run with a constrained size, then the scanner 
>> appears to have executed all three passes, or is at least coming to 
>> the end of the third pass, but before the scanner physcially returns 
>> to the start I get a kernal panic. The command I used for this test 
>> was
>> [MacCoylton:~] dave% scanimage -d 
>> "microtek:iokitscsi@<0161e1000000001e02a59e9b>" -x 30 -y 30
>> here's the debug trace immediately before the kernal panic, I copied 
>> this down by hand so forgive me if I have any typo's
>> [microtek] read_from_scanner...
>> [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 Transferred 6 bytes
>> [microtek] get_scan_status(6): 0, 118, 118 -> #0
>> [microtek] > 0 76 0 76 0 0
>> [microtek] read_from_scanner: gss busy, linewidth, remaining: 0, 118, 
>> 118
>> [microtek] sane_read: max_scsi: 1110, rem: 118, nline: 118
>> [microtek] .read_scan_data...
>> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:13924 isWrite:0
>> [sanei_scsi] isRead dst_size:13924
>> [sanei_scsi] Executing command
>> As you can see this stops on issuing a SCSI command, and the 
>> panic.log show the panic was within the adaptec driver.
>
> Kernel panic is an issue of the kernel ;) Even if it is triggered by 
> an application bug, it remains a kernel issue. After all, one of the 
> intentions of the separation between applications and the kernel is to 
> isolate buggy applications so that they can't bring down the whole 
> system. Another possible cause of the kernel panic could of course be 
> faulty hardware, like "forgetful" RAM.
>
> Abel

Agree. This is not good, and he Kernel or the Adaptec SCSI driver 
should deal with this. This is the only panic I've been seeing on this, 
system, and it is very repeatable, so not likely to be hardware.


Cheers

David

--Apple-Mail-1--291098809
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAsb3L+6rGH1tFACgRAi0bAJ0W1fEiwmAcTMQBbcTOTdW7ZiN+0QCfd9Jl
qmxnbSg5V75fhnLBSSX1MZk=
=Up/C
-----END PGP SIGNATURE-----

--Apple-Mail-1--291098809--