[sane-devel] strange SCSI behaviour

[abel deuring]

Alessandro,

>>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
> 
>  I added that check. The problem was that the first command
>  only returned after a couple of mins.

Ah, I missed that: Thought that only the second command needed so
much time.

> 
> 
>>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.
> 
>  that worked! It seems calling it before the first command
>  is enough. Do you think it should be called before every command?

Difficult to give a "definite" advice. Some Sane backends call TEST
UNIT READY for most if not all commands; others use this command
only quite seldom. Generally, it can't hurt to call TEST UNIT READY
for most SCSI commands. (more specifically, to have a loop in which
usleep() is called and TEST UNIT READY is sent, until either test
unit ready succeeds or the loop terminates/times out.) The
documentation for your scanner(s) might give a better hint, if or
where it is reasonable to call test unit ready.

An exception might be the read commands for the scan data:
Especially some older scanners have quite small internal buffers for
the scan data, and the additional delay from the TEST UNIT READY
commands might cause this buffer to become full, in turn causing
scan heads stops. On the other hand, the last time I have seen scan
head stops with my scanners was some years ago, when processor
speeds were far below 1 GHz.

Abel