Karl Heinz Kremer wrote: > > On May 1, 2004, at 3:37 PM, Klaus Dittrich wrote: > >> Klaus Dittrich wrote: >> >>> 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 >> >> >> Seems feed() in epson.c is not needed at all. >> I made it return SANE_STATUS_GOOD immediately and ADF scanning still >> works. >> Karl Heinz it seems the LOAD PAPER (0x19) from EPSON's >> 12_3065_esci_revl.pdf >> has other purposes. Do other scanners with ADF need this? > > > Yes, that's the reason it's there :-) It looks like I have to > blacklist some scanners (e.g. the 1640) so that this command is not used. > > Karl Heinz > Fine. So this issue is solved. Whenever you need a test with the 1640 mail me the code and you get an report.
-- Klaus
