Lawrence Glaister wrote:
> I just tried a usleep(2000) and a continue added into the EAGAIN condition
> in FDSource_get() instead of the break, and restored the code in
> RGBRouter_get(). This does seem to work. I noticed that the scanner does
> "backtrack" occasionally on large scans and this coincides perfectly with
> hitting the EAGAIN condition. It looks like the scanner is responding to usb
> read requests with a "try again later" and these are getting passed back up
> the chain... it is possible that other versions of usb kernel code will
> block on a read() until data is ready instead of returning with EAGAIN. I
> don't know what the scsi driver does, but if the reads dont return until
> data is available or an error occurs, this would explain the problems I have
> been seeing.
The sanei_scsi layer "catches" the EAGAIN error that can happen in the
write part of sanei_scsi_cmd; for reading a command's result data,
sanei_scsi uses a blocking read call.
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Mon Sep 25 2000 - 02:20:19 PDT