[sane-devel] strange SCSI behaviour

abel deuring adeuring at gmx.net
Sat Nov 25 15:33:16 CET 2006


Alessandro,

>    I just discovered the problem I had with my FilmScan 200
>  is not related to any particular command but just to the
>  first one sent to the scanner (just after modprobe)
> 
>   After that one, which receives a sense condition, everything
>  works perfectly.
> 
>   So, if there's a way to have the control immediately returned
>  to the driver as soon as the sense condition is issued, I would
>  just try reissuing the command and that should fix my problem.
> 
>   Any hint on how to do that?
> 
>  thanks!
> 
> [epson2] inquiry: EPSON   FilmScan 200    1.01
> [epson2] model  : FilmScan 200    1.01
> [epson2] reset
> [epson2] epson_cmd_simple: size = 2
> [epson2] epson_send: ESC @
> [sanei_scsi] scsi_req_enter: entered 0xb7c75008
> [sanei_scsi] sanei_scsi.issue: 0xb7c75008
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c75008
> [sanei_scsi] sanei_scsi.issue: 0xb7c75008
> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [sanei_scsi] sense buffer: 70 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
> [sanei_scsi] target status: 02 host status: 0000 driver status: 0008
> [sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 2
> [sanei_scsi]                      NOTE: This value may be bogus
> [sanei_scsi] scsi_req_enter: entered 0xb7c75008
> [sanei_scsi] sanei_scsi.issue: 0xb7c75008

Perhaps I am missing the point, but here one SCSI command finished
with an error, and below another SCSI command is sent to the device.
 Can't you check for the error here and decide to wait? Or handle
the sense data in another way? Admitted, the data of the sense
buffer is not very enlightening: UNIT ATTENTION does not tell very
much by itself, but you know which command caused the error, and the
documentation of the scanner may give a better clue what might have
happened.

Calling TEST UNIT READY before a "real" command is often also a good
way to avoid longer hangs.

Abel

> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c75008
> [sanei_scsi] sanei_scsi.issue: 0xb7c75008
> 
>  [~2 min delay here, the the aic7xxx driver queues an ABORT and the scanner resets ]
> 
> [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [sanei_scsi] sense buffer: 70 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
> [sanei_scsi] target status: 00 host status: 0001 driver status: 0000
> [sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 1
> [sanei_scsi]                      NOTE: This value may be bogus
> [epson2] epson_recv: expected = 1, got = 0
> [epson2] epson_cmd_simple: failed, Device busy
> 
>  this command has failed, but subsequent ones work
>  correctly.   
> 




More information about the sane-devel mailing list