[sane-devel] backends-1.0.14 scsi epson

[Klaus Dittrich]

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