[sane-devel] usb_control/bulk_msg: timeout

[Bill Moseley]

On Thu, 2 Jan 2003, Henning Meier-Geinitz wrote:

> The default timeout is 10 seconds, and it's expected to be enough for
> writes. You can try to increase this limit when loading the driver:
> 
> rmmod scanner; modprobe scanner read_timeout=60

Ok.  Did that.  BTW -- on boot the messages delay for about 4 seconds
each.

Now I still get:

Jan  2 11:55:14 bumby kernel: usb_control/bulk_msg: timeout
Jan  2 11:55:28 bumby last message repeated 11 times
Jan  2 11:55:28 bumby kernel: scanner.c: read_scanner(0): excessive NAK's received


> If this doesn't help, or you get more of these messages or if you get
> "excessive NAK's received" this is a sign for real errors. E.g.
> defective cables or defective hardware. Maybe also problems in the USB
> layer can cause this error, but I don't remember this being reported.

Ok.  Although to isolate that problem means buying a new scanner! Any
highly recommended USB models?


> If you have a UHCI host controller, try using the "uhci" instead of
> the "usb-uhci" module and vice versa.

I unloaded usb-uhci and loaded uhci.  Get exactly the same results.

> 
> > Then before sane will detect my scanner I have to remove/replace the USB
> > cable to the scanner one time.  That is, it's not correctly loaded at boot
> > for some reason.
> 
> Maybe a hotplug issue. Is the scanner listed in /proc/bus/usb/devices
> immediately after boot?

Yes it is (I assume -- it's a bit cryptic):

moseley at bumby:~$ fgrep 03f0 /proc/bus/usb/devices 
P:  Vendor=03f0 ProdID=0101 Rev= 1.00

But the scanner module is not loaded, so that's hotplug's responsibility
(cold-plug problem).  It's just not loading the "scanner" module on boot.

The only thing I can see in dmesg at boot is:

  hub.c: USB new device connect on bus3/1, assigned device number 2
  usb.c: USB device 2 (vend/prod 0x3f0/0x101) is not claimed by any active driver.

So fixing hotplug will fix the boot problem.


I just booted with 2.4.18 and had all the same problems.

Not related to sane, but I build 2.4.20 just a few days ago to resolve a
hotplug issue of modules not getting unloaded.  I have a usb Palm m500 and
hotplug calls upon loading the "visor" module this script:

  $ cat /etc/hotplug/usb/visor
  #!/bin/sh
  logger "********** Start ************"
  sleep 2
  /bin/su moseley -c /usr/bin/jpilot-sync
  logger "** end **"
  /sbin/rmmod visor usbserial
 
with 2.4.18 rmmod was not removing the modules.  Under 2.4.20 the modules
are removed but the hotsync fails.  /etc/hotplug/usb.agent runs that
script on visor load.  The weird things is the sync starts and then hangs.
If I comment out the jpilot-sync it runs fine.  If I rename the script and
press the hotsync button (which loads the modules) and then run the script
as root manually the hotsync works fine.  Very odd.  I've actually
received a Kernel Oops in some cases.

Very frustrating, as you can imagine.

> Well, which message do you mean? "scanner.c: open_scanner(1): Unable
> to access minor data"? This is ok, the scanner module is just a bit
> verbose.

That's what I assumed.


Thanks very much for your help!

-- 
Bill Moseley moseley at hank.org