abel deuring wrote: > sorry Klaus, I should have had a closer look into your other mail > containing the debug output. > > abel deuring wrote: > >> Klaus Dittrich wrote: > > [...] > >>> Starting with backend-1.0.13 the sanei_scsi layer has changed >>> and therefore I assume a bug in the scsi status handling, because >>> expect_ack() has not changed since sane-backends-1.0.12. >>> >>> Maybe one of the sanei_scsi developers can help here ? >> >> T >> >> As far as I can see, the only changes in sanei_scsi.c after the >> release of sane-backends-1.0.12 affecting Linux are indentation fixes >> and similar "formal" modifications. But the "real" code is the same. >> So I don't think that your problems are related to sanei_scsi.c. >> Anyway, could you send me the log output from trying a scan with the >> backend version 1.0.12 and a newer version, while SANEI_DEBUG_EPSON >> and SANE_DEBUG_SANEI_SCSI are set to 255? > > > the last lines from your debug data: > > dev_max(currently)=6 max_active_device=4 (origin 1) > def_reserved_size=32768 > >>> device=sg3 scsi2 chan=0 id=5 lun=0 em=0 sg_tablesize=96 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 > rb>> rcv: id=28 blen=1 dur=3ms sgat=0 op=0x08 > [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 05 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 1 > [sanei_scsi] NOTE: This value may be bogus > > That's the relevant part of the debug data you've sent: It simply > tells us that the scanner returned the status CHECK CONDITION for the > last command; The sense data means "illegal request". This generally > means that the SCSI command sent to the device contained some error. > Within sanei_scsi.c, that's "perfectly normal": This library does not > issue any SCSI commands by itself during a scan, it only "forwards" > commands issued by a backend to the kernel. So I assume that some > change in the Epson backend caused the error. > > Abel > > Thanks for your answer. I will try some more experiments. May be there is more code sent to the scanner than necessary in the case of ADF usage. With USB and linux-2.6.6-rc3 I get this ..
kernel: usbfs: USBDEVFS_BULK failed dev 11 ep 0x81 len 1 ret -110 error each time I use the ADF. Using flatbed works. -- Klaus
