[sane-devel] backends-1.0.14 scsi epson
Sat, 01 May 2004 19:57:53 +0200
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 ?
> 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)
>>> 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.