[sane-devel] Re: Nikon Coolscan IV and scanner.c funky result -75

Henning Meier-Geinitz henning@meier-geinitz.de
Wed, 18 Jun 2003 00:11:32 +0200


On Tue, Jun 17, 2003 at 10:26:08PM +0100, Major A wrote:
> > I'll try to summarize the problem (copied from a mail to
> > linux-usb-users):
> > 
> > | We want to read 42448 bytes (e.g. two scan lines). The buffer size is
> > | 32768 so that's the maximum we can do in one turn. The scanner returns
> > | only 21224 bytes (probably one scan line). So far that's ok.
> > | 
> > | The reason is that the next read reads only 9680 bytes instead of
> > | 21224. The scanner doesn't seem to be able to handle this.
> > 
> > So the scanner doesn't seem to like reads different from the size of
> > one scan line (?). I gueess the backend shouldn't try to read more
> > than the scanner is able to return.
> Ah, OK, but Coolscan2 strictly tries to read one scanline at the
> time. On the LS-40, this is a maximum of 23328 bytes (2916 pixels, 4
> channels each, 2 bytes per channel), which is less than 32k.

Ok. I was talking about a log created by vuescan:

Mar 18 07:02:26 kletskop kernel: scanner.c: read stats(0): result:0 this_read:32768 partial:21224 count:42448
Mar 18 07:02:26 kletskop kernel: uhci.c: uhci_result_interrupt/bulk() failed with status 500000
Mar 18 07:02:26 kletskop kernel: scanner.c: read stats(0): result:-75 this_read:9680 partial:9680 count:9680 
Mar 18 07:02:26 kletskop kernel: scanner.c: read_scanner(0): funky result:-75. Consult Documentation/usb/scanner.txt.
Mar 18 07:02:36 kletskop kernel: usb_control/bulk_msg: timeout

I remember similar reports about SANE but can't find a log at the

Hint for the bug reporter: A kernel logfile would be nice. For that,
enable USB debugging in make menuconfig (probably already enabled) and
debug messages in drivers/usb/scanner.h. This way we can see what's
exactly going on.

> > The Nikon Coolscan 4 seems to be the only scanner with this problem.
> > At least that's the only one I ever got reports for. So I really think
> > it's either a scanner or backend problem.
> Hmmm, that would be me... the scanner is a bit silly in the way that
> it tunnels SCSI commands across USB in a proprietary way, but it seems
> to work great in most cases, so it's probably not a hardware fault.

Maybe it just doesn't like "half-sent" buffers. On the other hand, if
you don't send more than one scan line I really don't know what's wrong.

> > By the way: The problem with coolscan/kernel scanner driver seems to
> > happen (have happened?) also with vuescan. Looks like a similar
> > scanning routine is used.
> That's right. VueScan also uses (used?) the scanner module, so go
> figure...

But vuescan does read more than 32k at once. At least that what's the
log shows. Maybe it's a different problem?