[sane-devel] FreeBSD and Microtek Scanmaker II

[abel deuring]

Matto Marjanovic wrote:

> 0) None of this generation of Microtek scanners supports SCSI disconnect.
>     Disconnect needs to be disabled for the scanner device (if not the 
>     whole bus), and you should expect the scanner to monopolize the entire
>     bus during a scan.
> 
> 1) The firmware in the earlier Microtek scanners is particularly brain-dead
>     with regards to timeouts like this.  Even worse, I have pretty extensive
>     documentation from Microtek --- *but every scanner deviates from the
>     documented behavior in some important way*.  Ugh.

At least you have some sort docs ;)

> 
> 2) With regards to this:
> 
>  >Looking through the log, it seems to me that something is wrong in 
>  >sanei_scsi.c. From your log file:
>  >
>  >[microtek] .stop_scan...
>  >[microtek] SPS:1b  0  0  0  0  0
>  >[sanei_scsi] sanei_scsi_cmd: scsi returned with status 10
>  >[microtek] SENSE!  fd = 0
>  >[microtek] sense = 00 00 00 00.
>  >scanimage: min/max graylevel value = 21/255
>  >[microtek] sane_start...
>  >
>  >The "stop scan" command returns an error (the "sanei_scsi" line), and 
>  >all following SCSI commands return errors too.
> 
>    The scanner probably *is* generating a SENSE error along with sense info.
>    However, it is not a SCSI-2 device --- it follows SCSI-1-CCM (something
>    like that) and it generates non-standard sense codes.

I don't think that the scanner returns any useful data in this case, 
except that it said "too busy to accept the SCSI command".

I've found a Scanmaker II buried deep in a cabinet and connected it to 
my Linux box. Here we get a similar error:

[microtek] .stop_scan...
[microtek] SPS:1b  0  0  0  0  0
[sanei_scsi] scsi_req_enter: entered 0x40825008
[sanei_scsi] sanei_scsi.issue: 0x40825008
dev_max(currently)=8 max_active_device=2 (origin 1)
  scsi_dma_free_sectors=64 sg_pool_secs_aval=320 def_reserved_size=32768
  >>> device=sg1 scsi0 chan=0 id=6 lun=0   em=0 sg_tablesize=127 excl=1
    FD(1): timeout=120000ms bufflen=131072 (res)sgat=4 low_dma=0
    cmd_q=1 f_packid=0 k_orphan=0 closed=0
      act: id=51 blen=0 t_o/elap=120000/20ms sgat=0 op=0x1b
[sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 2
[sanei_scsi] sanei_scsi_req_wait: waiting for 0x40825008
[sanei_scsi] sanei_scsi.issue: 0x40825008
dev_max(currently)=8 max_active_device=2 (origin 1)
  scsi_dma_free_sectors=64 sg_pool_secs_aval=320 def_reserved_size=32768
  >>> device=sg1 scsi0 chan=0 id=6 lun=0   em=0 sg_tablesize=127 excl=1
    FD(1): timeout=120000ms bufflen=131072 (res)sgat=4 low_dma=0
    cmd_q=1 f_packid=0 k_orphan=0 closed=0
      rcv: id=51 blen=0 dur=620ms sgat=0 op=0x1b
[sanei_scsi] sanei_scsi_req_wait: read 64 bytes
[sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Erfolg
[sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[sanei_scsi] target status: 7f host status: 0003 driver status: 0026
[microtek] end_scan:  OY! on stop_scan

The non-zero values for host status and driver status indicate that the 
scanner did not "accept" the command.

host status 3 means a timeout, but NOT a SCSI command timeout. driver 
status 26 means "driver timeout; suggest abort". The Linux part of 
sanei_scsi.c does not call the sense handler in this case (that would be 
pointless, because the scanner refused to do anything with the commands, 
so there is not sense data), but returns SANE_STATUS_DEVICE_BUSY.

>    I don't know about FreeBSD, but the Linux SCSI drivers always zero out
>    the sense codes --- this frustrates me to no end.  The Linux drivers are
>    trying to be clever, but they assume that *every* device is SCSI-2, and
>    since the codes do not conform to SCSI-2, they get squashed.
> 
>    Probably, FreeBSD is doing the same thing.  What both OS's *should* do
>    is just pass the poor sense codes up to the sense handler installed by
>    the backend, which should be smart enough to deal with them.  Instead,
>    the sense handler always gets called with a bunch of zeros!

Yes, they should do it, _if_ sense data is available. I tried to check 
this with Linux (but not very hard). I deliberately changed the data of 
the "start scan" command to "comm[6] = { 0x1B, 1, 1, 1, 1, 1 };" -- but 
the scanner simply accepted this command, while I expected to get some 
error back :(

> 
> 
> 3) For 3-pass scans, the backend needs to implement some kind of delay
>     between passes.  *However*, because of
> 
>       o the loss of the actual sense information
>       o the poor documentation
> 
>     it is unclear which commands can be sent during that delay, if that
>     delay can be polled (i.e. ask the scanner if it is ready) or if it
>     must be guessed, etc, etc.
> 
>     This is the part of maintaining this backend that I despise.

I think that the backend should check for the error 
SANE_STATUS_DEVICE_BUSY and it should retry the failing commands for a 
reasonable amount of time. In the case of the 3-pass scans, this could 
be 30 seconds or so.

Abel