Steve Underwood wrote:
>
> Patrik Stähli wrote:
>
> > I wrote:
> >
> > <snip>
> >
> > > Debug output of sane dll and snapscan backend is here:
> > > http://n.ethz.ch/student/staehlip/download/sane.log
> >
> > Did someone already look at the debug output?
> > I think that there are way too much 0's in the 'inquiry' sections, but I
> > don't know what correct values should look like.
> > It would be really helpful if someone could provide the same debug
> > output (SANE_DEBUG_DLL=255 SANE_DEBUG_SNAPSCAN=255) of a _working_ Model
> > 620S...
>
> Yes, there are far too many zeros. The 640U has been reported to work with
> 1.0.3 + the USB add ons. The 610+ (SCSI) and 620S seem to work OK too. I
> would expect your 640S to be very similar to these. I don't think the
> output from a run on my 610+ will help much. It looks like your run, until
> the inquiry section. Then I get sane numbers for all the values. Perhaps
> this is not a scanner or sane problem, but a SCSI one. I have never tried a
> 2.4 test kernel. Has anyone else has success with one?
I used some of the 2.3.99 versions without any problems, although with
different SCSI adapters (NCR53810 and Adaptec 2940) and a different
scanner.
But of course there might be problems with the aha1502 or the atp870u
(Patrik, is this the one you are using??) drivers. I was quite irritated
about the following lines in src/linux/drivers/scsi/atp870u.c, line 514
(ok, taken from Linux 2.2.13...):
if (ata_cdbu[h][0] == 0x12) {
if (workrequ->request_bufflen > 0x24) {
workrequ->request_bufflen = 0x24;
ata_cdbu[h][4] = 0x24;
}
}
And line 594 in atp870u.c from kernel version 2.3.99-pre2:
/*
* Why limit this ????
*/
if (dev->ata_cdbu[0] == INQUIRY) {
if (workrequ->request_bufflen > 0x24) {
workrequ->request_bufflen = 0x24;
dev->ata_cdbu[4] = 0x24;
}
}
I'm far away from understanding the driver, but this "smells" as if the
data size for the INQUIRY command is being clipped to 0x24 bytes.
Unfortunately, there is no reliable check for the Linux SG driver, how
many bytes were actually transferred. A quote from Douglas Gilbert's SG3
documentation (http://www.torque.net/sg/p/scsi-generic_v3.txt):
>int resid; /* [o] dxfer_len - actual_transferred */
> This is the residual count from the data transfer. It is 'dxfer_len'
> less the number of bytes actually transferred. In practice in only
> reports underruns (i.e. positive number) as data overruns should
> never happen. At time of writing no SCSI adapters supported 'resid'
> but hopefully this will soon change. This value will be zero if
> there was no underrun or the SCSI adapter doesn't support this
> feature.
Thus, there is no way to check in sanei_scsi.c or "below", if my
suspicion is right. But it could help to initialize pss->cmd in function
inquiry in snapscan-scsi.c to something else than zero. (Well, the CDB
should not be initialized with a non-zero value, but data block
following the CDB...)
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 : Fri Oct 20 2000 - 08:52:41 PDT