[sane-devel] Re: Nikon Coolscan IV and scanner.c funky result -75
Tue, 17 Jun 2003 23:02:21 +0200
On Tue, Jun 17, 2003 at 09:20:27PM +0100, Major A wrote:
> Hope you don't mind me also sending a copy to the SANE list.
> > often I get this strange error : scanner.c blah funky result:-75
> > blah. I have been getting this for a while and once it happens,
Error 75 is EOVERFLOW. That's usually caused in connection with UHCI
USB controllers in "babble" condition. That means something happend on
the USB that the device (or the host) did not expect. It seems to
happen with some USB devices when you send too long buffers or read
more data than the scanner expected.
> OK, that sounds familiar, but I still don't know a solution to it. The
> tricky bit about USB is that if there's a bug in one of the generic
> drivers, it might go unnoticed for very long because most hardware
> doesn't trigger it. I'm pretty sure this has to do with the USB system
> in Linux, and I think it has been reported to the USB team.
There is a known problem with the kernel USB driver that occurs, when
the user space program tries to read more data than the scanner wants
to provide. Well, it's not really a problem in my view, more a kind of
bad interaction. Some discussion about this can be found on the
linux-usb-users lists. I've asked the old maintainers and they say
that the behaviour is intended.
I'll try to summarize the problem (copied from a mail to
| 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.
While the scanner driver's behaviour isn't the optimum (it could try
to read 21224 bytes twice), I don't think it's wrong. There was a
short read and that's a way to signal it.
> user-level program like SANE should not be allowed to crash the
> computer like that, so it's certainly not exclusively a SANE problem.
That's true. On the other hand the only crash concerning the USB
scanner driver is when you open /dev/usb/scanner*, unplug the scanner,
and read or write to the scanner. I'm talking about 2.4.21 (and the
later -pre versions) here, older versions may have more bugs.
> > the only solution is to reboot - the scanner module cannot be
> > unloaded, it says it is always in use.
Please show me the decoded OOPS message, if it's 2.4.21(-pre).
Otherwise updating the kernel may help.
> The scanner module is more and more obsolete. Most backends in newer
> SANE releases (from 1.0.11 I think) use libusb,
They are able to use libusb. If the scanner driver is loaded, it will
> which on Linux uses usbdevfs to access the hardware. This should be
> much more robust.
For most scanners it works better. For some it doesn't (E.g. Mustek
600CU). But basically, you are right.
> Could you please try the latest SANE release and make sure
> libusb (including development files) is installed when you build it?
And tell us the kernel version :-)
> > scanner: HP5300C and that works just great with hpusb driver.
Different USB driver :-)
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.
> > Also,
> > I have a Nikon (speaking of the brand loyalty :) D100 digital camera
> > and just managed to get it connected (USB) to linux using gphoto2
> > and hotplug. They both work great - so it seems that I got the USB
> > system right.
> Unfortunately, as I said above, this is not a guarantee that the USB
> system works all right. I've been using the VIA USB 2.0 controller on
> my mainboard for months now without any trouble, but the moment I
> connected an external USB 2.0 hard disk to it, things started going
> very wrong. The solution is still outstanding, the USB team are
> working on it...
I've heard similar reports and they seem to be fixed with 2.4.21. But
your milage may vary...
> > VueScan. Great program, I just wish to have bought it when it was
> > only $40 for lifetime updates, now it is $80 for a year :(
> Seems that SANE is finally taking away some of Ed's income...
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.