[sane-devel] FreeBSD and Microtek Scanmaker II

[abel deuring]

Nakal wrote:
> On Monday 16 June 2003 21:16, abel deuring wrote:
> 
> 
>>The first error occurs immediately after a "read", and this at least
>>does not contradict my suspicions about the timeout problems. But we
>>could get a better clue, if you add a "SANE_DEBUG_MICROTEK=255". The
>>DLL debug output is less interesting.
> 
> 
> OK. I attached the output of the command:
> SANE_DEBUG_MICROTEK=255 SANE_SCSICMD_TIMEOUT=180 scanimage -v -d 
> 'microtek:/dev/scanner' --mode color -y 50 > microtek-on-fbsd48.log 
> 2>&1

What I meant, was a combination of the log output of the Sane SCVSI 
library and of the Microtek backend ;) This allows in many cases to see, 
which SCSI command issued from a certain function of the backend causes 
an error. But from the log data of microtek backend alone I think that 
this is a pure backend problem. This is the relevant part:

[microtek] get_scan_status(6): 27, 0, 20736  -> #0
[microtek] > 1b  0  0  0 51  0
[microtek] get_scan_status:  busy, retry in 5...
[microtek] SENSE!  fd = 0
[microtek] sense = 00 00 00 00.
[microtek] get_scan_status(6): 27, 0, 20736  -> #1
[microtek] > 1b  0  0  0 51  0
[microtek] get_scan_status:  busy, retry in 10...
[microtek] SENSE!  fd = 0
[microtek] sense = 00 00 00 00.
[microtek] get_scan_status(6): 27, 0, 20736  -> #2
[microtek] > 1b  0  0  0 51  0
[microtek] get_scan_status:  busy, retry in 15...
[microtek] SENSE!  fd = 0
[microtek] sense = 00 00 00 00.
[microtek] get_scan_status(6): 27, 0, 20736  -> #3
[microtek] > 1b  0  0  0 51  0
[microtek] get_scan_status:  busy, retry in 20...
[microtek] sane_start:  get_scan_status fails

The lines "get_scan_status:  busy, retry..." are only printed, if the 
SCSI command "get scan status" does not produce a SCSI error (i.e., 
nothing went wrong during the transport of the SCSI data from the 
scanner to the application). So the SCSI system (kernel, kernel drivers 
or Sane's SCSI libraray) is probably not involved, but the 
get_scan_status in the Microtek backend is perhaps a bit too 
"impatient". But the maintainer of the Microtek backend can probably 
give a more qualified comment.

Abel