[sane-devel] Sane, Microtek ScanMaker II and Mac OS X SCSI
David B Brown
david_b_brown@mac.com
Sun, 29 Feb 2004 22:56:40 +0000
--Apple-Mail-10-1003952439
Content-Type: multipart/alternative; boundary=Apple-Mail-9-1003952429
--Apple-Mail-9-1003952429
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
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@tsl.uu.se tel: +46 18 471 32
>> 58
>> http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35
>> 13
>> ______________________________________________________________________
>> __
>>
--Apple-Mail-9-1003952429
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII
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
<fixed>ExecuteSCSITask </fixed>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:<color><param>FFFD,0000,0000</param>iokitscsi@<<015d10000000001e0ed67236></color>
[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
<color><param>FFFD,0000,0000</param>iokitscsi@<<015d10000000001e0ed67236></color>
[microtek] sane_start...
Now when I look at the find_scanners code it appears we are using the
<fixed>sanei_scsi_find_devices_stuc_api, </fixed>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:
<excerpt>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
<color><param>FFFC,0000,0000</param>[sanei_scsi] David Executing
command. MAX_DATA = (0x00020000), 131072</color>
[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:
<excerpt>David B Brown wrote:
<excerpt>[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...
</excerpt>
Patch is available at http://www.ellert.se/twain-sane/patches.html
Mattias
--
________________________________________________________________________
mattias.ellert@tsl.uu.se tel: +46 18 471 32
58
http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35
13
________________________________________________________________________
</excerpt></excerpt>
--Apple-Mail-9-1003952429--
--Apple-Mail-10-1003952439
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)
iD8DBQFAQm4o+6rGH1tFACgRAhC9AKDQhF3H4i4abQpZvT9JjxqQi+O+lgCdGZT/
yS16sptAXM1vsKNXLYCeDhA=
=n2XN
-----END PGP SIGNATURE-----
--Apple-Mail-10-1003952439--