Hi
Thanks for the response.
As mentioned in my original note, I have another native Mac OS X tool
called VueScanX from which I can do 3 pass color scans from, so my
SCSI bus and the Adaptec driver must be ok. The reason I'm trying to
get sane working is that I only have a demo version of vuescan and is
VERY slow to scan.
here's some trace using the environment variables you suggested. In
this case I have just done a greyscale preview, and have now hit the
scan button and here is what I get :-
[microtek] sane_start...
[microtek] sane_get_parameters...
[microtek] sane_get_parameters: non-color
[microtek] sane_get_parameters: res_code = 100 (64)
[microtek] sane_get_parameters: dots_per_mm: 11.811024
[microtek] sane_get_parameters: units_per_mm: 11.811024
[microtek] WIDTHPIX: before exp: 2540
[microtek] sane_get_parameters: lines: 4188 ppl: 2540 bpl: 2540
[sanei_debug] Setting debug level of sanei_scsi to 255.
[microtek] .wait_ready 0...
[microtek] wait_ready failed (0)
[microtek] wait_ready failed (1)
[microtek] wait_ready failed (2)
[microtek] wait_ready failed (3)
[microtek] wait_ready failed (4)
[microtek] wait_ready failed (5)
[microtek] wait_ready failed (6)
[microtek] end_scan...
[microtek] sane_cancel...
[microtek] end_scan...
Here's a second scenario where I try to do a preview scan in color the
first pass of the preview scan takes place and then as the scanner head
is return to the start the following trace appears :-
[microtek] end_scan...
[microtek] .stop_scan...
[microtek] SPS:1b 0 0 0 0 0
[microtek] end_scan: OY! on stop_scan
[microtek] sane_start...
[microtek] sane_get_parameters...
[microtek] sane_get_parameters: regular 3-pass color
[microtek] sane_get_parameters: res_code = 19 (13)
[microtek] sane_get_parameters: dots_per_mm: 2.244094
[microtek] sane_get_parameters: units_per_mm: 11.811024
[microtek] WIDTHPIX: before exp: 484
[microtek] sane_get_parameters: lines: 798 ppl: 484 bpl: 484
[microtek] set_pass_parameters: three-pass, on 2
[sanei_debug] Setting debug level of sanei_scsi to 255.
[microtek] .wait_ready 0...
[microtek] wait_ready failed (0)
[microtek] wait_ready failed (1)
[microtek] wait_ready failed (2)
[microtek] wait_ready failed (3)
[microtek] wait_ready failed (4)
[microtek] wait_ready failed (5)
[microtek] wait_ready failed (6)
[microtek] end_scan...
[microtek] sane_cancel...
[microtek] end_scan...
[microtek] sane_control_option (opt=4,act=1,val=0x1460a18,info=0x0)
Hope this helps
Thanks
David
On Friday, August 29, 2003, at 10:48 AM, abel deuring wrote:
> David B Brown wrote:
>>
>> Hi,
>>
>> new to sane so bear with me.
>>
>> I installed version 1.0.12 via Fink. I'm using xsane 0.89 as my front
>> end, but have also tried just using scanimage from the command line
>> with the same symptoms. I'm running Mac OS X 10.2.6, with a
>> Scanmaker II attached to and Adaptec 2906 SCSI card. The scanner
>> works ok if slowly with VueScanX, so I guess that basically the
>> SCSI bus and the Scanner are working ok.
>>
>> The symptoms are similar to those discussed between June 10th and
>> June 19th 2003 under the thread heading FreeBSD and Microtek Scanmaker
>> II, in that if I try to scan in color it fails after the first pass,
>> although if I scan in grayscale it works ok (single pass).
>
> I don't think that the problems are similar. The FreeBSD/CAM part of
> sanei_scsi.c (that's Sane's internal library for OS-independent SCSI
> device access) had a bug in it's SCSI command error handling, while the
> "Unexpected bus free" messages you see with MacOS X indicate a
> low-level
> SCSI protocol problem.
>
> These old Microtek scanners don't have the best SCSI protocol
> implementation (for example, they respond to some SCSI commands on all
> LUNs, formally suggesting that you have actually 8 scanners
> installed...), so I would guess that the adapter driver and the scanner
> are to be blamed. But it might be possible to "configure" the access to
> a certain SCSI device (selection of transfer speed, disabling
> disconnect...) somehow with the MacOS SCSI drivers. The people who
> wrote
> the MacOS part of sanei_scsi.c might have better comments.
>
>>
>> Looking in /var/log/system.log I can see the following
>>
>> [G4:~] dave% more /var/log/system.log | grep Adaptec
>> Aug 28 20:12:30 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:14:21 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:22:44 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:24:37 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:25:38 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:27:29 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:32:05 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:33:57 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:35:32 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:37:23 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:58:23 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 20:59:30 G4 mach_kernel: Adaptec error: PAL_bit_bucket: not in
>> data phase?
>> Aug 28 20:59:30 G4 mach_kernel: Adaptec CARD DISABLED because of
>> unrecoverable error!
>> Aug 28 20:59:30 G4 mach_kernel: Adaptec warning: Resetting SCSI bus.
>> Aug 28 20:59:35 G4 mach_kernel: Adaptec warning: Resetting SCSI bus.
>> Aug 28 22:25:32 G4 mach_kernel: Adaptec warning: Unexpected bus free
>> Aug 28 22:26:14 G4 mach_kernel: Adaptec error: PAL_bit_bucket: not in
>> data phase?
>> Aug 28 22:26:14 G4 mach_kernel: Adaptec CARD DISABLED because of
>> unrecoverable error!
>> Aug 28 22:26:14 G4 mach_kernel: Adaptec warning: Resetting SCSI bus.
>> Aug 28 22:26:20 G4 mach_kernel: Adaptec warning: Resetting SCSI bus.
>>
>> Is it possible that this is the same problem?
>>
>> Is it possible that since I installed via fink, I don't necessarily
>> have the patch that is referred to in the discussion mentioned above >> ?
>> If so how would i go about installing the patch ?
>>
>> Is there some command I can use to provide more trace to help
>> diagnose the problem ?
>
> Running the Sane frontend with the environemnt variables
> SANE_DEBUG_MICROTEK=255 and SANE_DEBUG_SANEI_SCSI=255 might perhaps
> give
> a bit more insight, where the problem occurs. But again, I think that
> the authors of the MacOS X part of sanei_scsi.c probably have better
> suggestions.
>
> Abel
