[sane-devel] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[abel deuring]

Julien BLACHE wrote:
> BERTRAND Joël <joel.bertrand at systella.fr> wrote:
> 
> Hi,
> 
>> I use a Snapscan 1236s with xsane on an i386 (K6-III/400, 256 MB,
>> Adaptec 2940U, kernel 2.6.20.1) without any trouble. If I use the same
>> scanner on an U2 (2xUltraSPARC-II/296 MHz, 2 GB, Happymeal-ESP, kernel
>> 2.6.21-rc7), sane-find-scanner does not find any scanner but this
>> scanner is shown in /proc/scsi/scsi. Both stations run lenny.
> 
> [Summary for sane-devel]
> This is the old "Linux SG3 interface does not work in
> 32/64bit mixed environments". The most recent reference to this
> problem I could find is the discussion that took place on sane-devel
> (and some other lists at the same time) back in early 2003.
> 
> 
> This bug made me dig a bit into this issue this afternoon; I don't
> remember reading any of that yet, so here is what I found:
> 
>  - sanei_scsi doesn't work using the Linux SG3 interface in 32/64bit
>    mixed environments
>  - sg3-utils' sg_inq, which does something equivalent to what
>    sane-find-scanner does, that is sending SCSI INQUIRY commands, does
>    work
> 
> As it turns out, sanei_scsi uses the asynchronous SG3 interface (using
> read/write calls on /dev/sgX), and sg3-utils now uses the SG_IO ioctl
> interface.
> 
> The SG_IO ioctl benefits from the 32/64bit ioctl compatibility layer,
> hence sg3-utils has no problems in a 32/64bit mixed environment.
> 
> 
> So, in a nutshell, sanei_scsi needs to move to SG_IO instead of the
> current interface if we want to support the more and more common mixed
> environment case.
> 
> 
> Attached is a proof of concept patch, tested on a Microtek scanner
> (microtek2 backend); the scanner works like a charm with this code, it
> feels like it even goes faster than using the async interface on the
> same machine (with a 32bit kernel, last time I tried it took something
> like 10 minutes to scan an A4 page with the default settings on an idle
> machine, it's under 1 minute now).
> 
> 
> I am not entirely sure that my patch behaves properly when an error
> occurs; I don't know anything about sanei_scsi (well, didn't know
> anything until today), so if someone familiar with sanei_scsi could
> take a look, maybe we could fix this bug for good :-)
> 
> (note: with the SG_IO ioctl, we're loosing command queuing to the
> scanner; doesn't look terribly important to me given how my test
> turned out ...)

Julien,

are you sure that the 32/64 bit problem is _not_ fixed for the
read/write interface, but only for the ioctl? If so, we should indeed
use the ioctl call in sanei_scsi. But if we do so, we should at the same
time get rid of all the queue management. If you compare the Linux part
of sanei_scsi with that for other operation systems, you will note that
the code is much simpler, mostly due to the fact that these OSes all use
a simple ioctl instead of the write/read logic. OK, this would also mean
to change a bit more in sanei_scsi, especially it would mean that the
check for the availability of the SG_IO ioctl would be moved from run
time to compile time.

But I am quite surprised that your Microtek scanner is so much faster
with the ioctl is than the current implementation. When Doug Gilbert had
implemented command queuing for the SG driver, I noticed a considerable
performance gain for the Sharp JX250 scanner. The latency between the
end of a SCSI command and the start of the next command (from the
viewpoint of the scanner) is lower, if the command has already been
issued by the application, so the kernel can start the next command
immediately, without a context switch to the application. On the other
hand, this was at a time, when processors had clock speeds of 200 or 300
MHz. With modern processors, the latency is small enough even if "kernel
level queueing" is not used.

Abel