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
