[sane-devel] Mac OS X 10.3.3- Sane Backend 1.0.14 - Microtek ScanMaker II - New Information

Sat, 08 May 2004 15:11:18 +0200

since noboby with more knowlegde about MacOS has yet answered, here are 
my 2 cents:

David B Brown wrote:
> Hi,
> 
> every time a new version of the Sane Backend's becomes available I 
> always have another go to see if anything has changed to make my 
> configuration work. I also find that when I come back to this afresh I 
> always get a little further forward.
> 
> When you run scanimage, the Microtek scanner incorretly reports itself 8 
> times, each under a different LUN, this has been consistent since the 
> new Max OSX SCSI code was implemented to support Mac OS X 10.3.
> 
> [MacCoylton:~] dave% scanimage -L
> device `microtek:iokitscsi@<016333000000001e2a70b923>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<016338000000001e28c472d6>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<01633a000000001e18c239cd>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<0162c4000000001e05d02fe7>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<01633d000000001e0530106a>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<0162cc000000001e04869288>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<0162cf000000001e03c78ee9>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> device `microtek:iokitscsi@<0161e1000000001e02a59e9b>' is a Microtek 
> ScanMaker II/IIXE flatbed scanner
> [MacCoylton:~] dave%
> 
> If you check using ioreg, each of these is on the same SCSI ID, but a 
> different LUN, the last one reported is actually on LUN 0.
> 
> If I run scanimage without specifically specifying a device, then I 
> always get and error about the scsi buffer being smaller than one scan 
> line. The error is a bit of a red herring, and the real issue is that 
> the code is trying to communicate with the scanner using the wrong LUN, 
> in this case on LUN 7 in the above example which is the first one listed.
> 
> 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.

> 
> If I run scanimage with the -d option set to the last device listed ie 
> the one thats LUN 0, the scan actually starts. I then have two scenarios 
> each with there own problems as follows
> 
> 
> Scenario 1:- If I run with an unconstrained size, then the first pass 
> happens ok, and then scanimage exists with an error before the scanner 
> physically returns to the start for the second pass. Here's some debug 
> trace:-
> 
> [microtek] sane_read: buffsize: 130900, unscanned: 13
> [microtek] pack_into_ring...
> [microtek] pack_into_dest...
> [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 0
> [microtek] sane_read...
> [microtek] pack_into_dest...
> [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 32768
> [microtek] sane_read...
> [microtek] pack_into_dest...
> [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 65536
> [microtek] sane_read...
> [microtek] pack_into_dest...
> [microtek] pack_into_dest: rl: 32596 sz: 130900 hc: 98304
> [microtek] sane_read...
> [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 Trasferred 6 bytes
> [microtek] get_scan_status(6): 0, 850, 13 -> #0
> [microtek] > 0 52 3 d 0 0
> [microtek] read_from_scanner: gss busy, linewidth, remaining: 0, 850, 13
> [microtek] sane_read: max_scsi: 154, rem: 13, nlines: 13
> [microtek] .read_scan_data...
> [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:11050 isWrite:0
> [sanei_scsi] isRead dst_size:11050
> [sanei_scsi] Executing command
> [sanei_scsi] ExecuteTaskSync OK Trasferred 11050 bytes
> [microtek] sane_read: buffsize: 11050, unscanned: 0
> [microtek] pack_into_ring...
> [microtek] pack_into_dest...
> [microtek] pack_into_dest: rl: 11050 sz: 130900 hc: 0
> [microtek] sane_read...
> [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
> [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.

> [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