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

David B Brown david_b_brown at mac.com
Sun Feb 29 22:56:40 GMT 2004


Hi,

	I did some further debugging on this, hope I'm going in the right  
direction, and this helps.

	At the point where the issue happens, if I'm reading the code  
correctly, the backend hasn't really started scanning yet, it is trying  
to send a  get_scan_status command to which it is expecting a 6 byte  
response which tells it, if the scanner is busy, the length of a line,  
and the number of unscanned lines.

	Watching this as it executes it appears that the  call to  
ExecuteSCSITask appears to be timing out, but this doesn't appear to be  
trapped. Instead the routine returns 0 for the length of a line, and 0  
for the number of unscanned lines. The backend then goes on to  
calculate the size the SCSI buffer needs to be to read from the scanner  
based on these values which of course are both zero, and this is what  
generates the error.

	If you look at the whole log the first think that happens is the  
backend searches for scanners on the scsi bus. For some reason the you  
see it recognizing this scanner at all 8 addresses on the scsi bus.  
When it then 'opens' the scanner to start the actual scanning process I  
think it uses the last one found. Here's the relevant pieces of the  
trace :-

	There are eight sections like this in total, this is the last of the  
sections, in the previous 7 the device found had a different number at  
the end:-

[sanei_scsi] David: Found:iokitscsi@<015d10000000001e0ed67236>
[sanei_debug] Setting debug level of sanei_scsi to 25.
[sanei_scsi] sanei_scsi_cmd FD: (fd=0)
[sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:96 isWrite:0
[sanei_scsi] isRead dst_size:96
[sanei_scsi] David Executing command. MAX_DATA = (0x00020000), 131072
[sanei_scsi] ExecuteTaskSync OK Trasferred 96 bytes
[microtek] parse_inquiry:  Not an E6 -- pretend recal cannot be  
disabled.
[microtek]  === SANE/Microtek backend v0.13.1 ===
[microtek] ========== Scanner Inquiry Block ========mm



Here's its starting to read the actual processes of opening and setting  
up the scanner for scanning, and trying to use the last device it  
found.

[microtek] sane_get_devices
[microtek] sane_open iokitscsi@<015d10000000001e0ed67236>
[microtek] sane_start...


Now when I look at the find_scanners code it appears we are using the  
sanei_scsi_find_devices_stuc_api, version of the code, which looks like  
it only searches by vendor and model, and not by SCSI id.  My scanner  
is on scsi ID 1, I think the issue is something to do with the fact the  
scanner responds to inquiry command on all SCSI ID's, and the backend  
is using the last device found when it starts the actual scanning  
process, not necessarily the one my scanner is actually on.  Is the  
last device found likely to be SCSI ID 7, is this the same ID used but  
the SCSI interface card, or does the card use ID 0? If I change my  
scanner to ID 7, do you think tis might make a difference ?


hope this helps
	
Cheers
	
David



On 27 Feb 2004, at 16:58, David B Brown wrote:

> Mattias,
>
>
> 	thanks for the quick response. I downloaded the sources from your  
> website,  did the patch you suggested, but still not joy. So I added a  
> little extra to a  DEBUG statement to be sure as follows ,
>
> 	DBG (5, "David Executing command. MAX_DATA = (0x%08x), %d\n",  
> MAX_DATA, MAX_DATA);
>
>  and sure enough this show that the patch has been applied and  
> MAX_DATA is set to 128*1024.
>
> 	Here's the Debug trace I get :-
>
>  dave% /usr/local/bin/scanimage -x 25.6 -y 25.6 > img.pnm
>
> .......
>
> [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] David Executing command. MAX_DATA = (0x00020000), 131072
> [sanei_scsi] ExecuteTaskSync OK Trasferred 10 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] David Executing command. MAX_DATA = (0x00020000), 131072
> [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] David Executing command. MAX_DATA = (0x00020000), 131072
> [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] David Executing command. MAX_DATA = (0x00020000), 131072
> [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!
> [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] David Executing command. MAX_DATA = (0x00020000), 131072
> [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:sane-backends-2004-02-15-cvs-macosx/src/sane-backends 
> -2004-02-15-cvs] dave%
>
> Cheers
>
> David
>
> On 27 Feb 2004, at 11:03, Mattias Ellert wrote:
>
>> David B Brown wrote:
>>> [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!
>>> [microtek] end_scan...
>>
>> Patch is available at http://www.ellert.se/twain-sane/patches.html
>>
>> 	Mattias
>>
>> -- 
>> ______________________________________________________________________ 
>> __
>>
>> mattias.ellert at tsl.uu.se                           tel: +46 18 471 32  
>> 58
>> http://www.tsl.uu.se/~ellert/                      fax: +46 18 471 35  
>> 13
>> ______________________________________________________________________ 
>> __
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6062 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20040229/af1a1ff5/attachment.bin>
-------------- 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/20040229/af1a1ff5/attachment.sig>


More information about the sane-devel mailing list