[sane-devel] Help with Canon 2700F

[abel deuring]

Lutz wrote:

> to me, it looks like that the (working) Epson scanner gives much more info 
> than the canon does.

right: the Epson seems to be OK, while something is broken with the
FS2700, see below.

> I already tried to debug (eclipse, cdt) the call - but I did not manage to 
> have the source included when init() is called - the closest I got to, is 
> that sense_handler in canon.c seems to be called with a null argument - seen 
> in the debug output too - but here the mess has happened already.

The null argument in the sense handler is OK. Regarding debugging:
gdb is your friend ;) Besides, you can grep for strings like
"attach: sending TEST_UNIT_READY" in the sources files of the
backend; you should be able to quickly find the correct lines; here
you can add for example additional DBG calls.

> [canon] >> sane_init
[...]
> [canon] >> inquiry

... the first SCSI command is sent to the scanner; the usual
INQUIRY; works fine.

> [canon] << inquiry
> [canon] attach: sending TEST_UNIT_READY
> [canon] >> test_unit_ready
> [sanei_scsi] scsi_req_enter: entered 0x80741d8
> [sanei_scsi] sanei_scsi.issue: 0x80741d8
> dev_max(currently)=32 max_active_device=5 (origin 1)
>  def_reserved_size=32768
>  >>> device=sg1 scsi2 chan=0 id=1 lun=0   em=0 sg_tablesize=128 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=1 blen=0 dur=2ms sgat=0 op=0x00
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 2
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x80741d8
> [sanei_scsi] sanei_scsi.issue: 0x80741d8
> dev_max(currently)=32 max_active_device=5 (origin 1)
>  def_reserved_size=32768
>  >>> device=sg1 scsi2 chan=0 id=1 lun=0   em=0 sg_tablesize=128 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=1 blen=0 dur=2ms sgat=0 op=0x00
> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [sanei_scsi] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00
> [sanei_scsi] target status: 02 host status: 0000 driver status: 0008
> [canon] >> sense_handler
> [canon] canon_sense_handler(3, 0x8074230, (nil))
> [canon] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00
> [canon] sense message: problem not analyzed (unknown SCSI class)
> [canon] << sense_handler
> [canon] << test_unit_ready

... and the second command (TEST UNIT READY) fails. The reason is
unknown, mostly, because Canon does not release proper
documentation. Without the docs, it's hard to give a more specific
analysis, what the data in the sense buffer exactly means.

The authors of the backend decided to not let the backend continue
to access the scanner in this case -- a reasonable decision. You
might though try to ignore this specific error and patch the backend
accordingly.

Abel