Red Hat Bugzilla – Bug 200122
HP ScanJet 5300C USB scanner does not work using errata kernels
Last modified: 2008-02-13 21:34:55 EST
Description of problem:
Using latest errata kernel (2.6.17-1.2142_FC4) on x86_64 I get the following
message while plugging in my HP ScanJet 5300C scanner:
usb 2-1: new full speed USB device using uhci_hcd and address 6
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: can't set config #1, error -71
Bus 002 Device 006: ID 03f0:0701 Hewlett-Packard ScanJet 5300c/5370c
It used to work with an older kernel. I don't know when it broke but it
definately works fine with 2.6.11-1.1369_FC4 (I have both installed and reboot
into the other when I want to use the scanner).
The result is that the scanner does not work at all.
Version-Release number of selected component (if applicable):
Kernel 2.6.17-1.2142_FC4 on x86_64
Steps to Reproduce:
1. Plug in scanner into any USB port (with or without using a hub inbetween)
Scanner doesn't work at all
Scanner should work.
The motherboard is an ASUS K8V SE with an Athlon64 3000+. The machine has 1GiB
of memory (2x512MiB). The chipset is a Via K8T800 with the VIA 8237 southbridge.
No other problems with the machine.
Looking through the lsusb -v output shows the following :
It is a self powered unit which should not be affected by the usb power changes
in recent kernels.
The problem appears regardless of what port it is plugged in or how it's
connected (directly / through a hub).
Any other info available upon request.
I'm not very happy. The jump between versions is too great... I'll what
I can do. Maybe we can just brute-force it by collecting the usbmon trace
and looking at it carefuly.
What is the result of "grep USBMON /boot/config*" ?
The grep produced nothing. grep USB_MON /boot/config* however showed it to be
enabled for all 2.6.16 kernels and up and as a module for the 2.6.11 kernel.
Another thing to add : I didn't start using the scanner until 2.6.15 and it
didn't work at that point. So it's somewhere between release and 2.6.15. Is
there a place to get hold of all the kernels inbetween ? I have nothing against
testing, I just don't know if I can get hold of all (or some of) the kernels.
This is what I have installed currently:
I think it's easiest if I somehow can get hold of all (some) of the errata
kernels inbetween somehow and test those to figure out where it breaks and THEN
go cracking with usbmon. What do you think?
I've downloaded usbmon now however. Let me know what you want me to do.
(I am actually a programmer, I just never touched USB neither in kernel or out
of kernel before, I have however modified the kernel before for my own needs,
etc - these kernels are pristine redhat though).
I'm sorry for the confusion about the configuration variable's name.
There is no need to download anything before usbmon is used. There should
be a memo on its use in this file:
If it's not there, please run "yum install kernel-doc".
Finding old kernels is going to be a lot of trouble for either of us.
We have them stored internally, but uploading the number necessary
for bisection is going to blow my quota at people.redhat.com.
Let's get the usbmon trace first, maybe it's something obvious.
Usually it's the command right before the -71. Then I can check
when it appeared.
Created attachment 133153 [details]
USBmon trace of plugging the device in
Any progress or did you miss that I upped the trace?
Or anything else you want me to do or try ?
I didn't have a moment to look at it. Probably after 8/12.
I'm also seeing this error with enough similarities for to suspect it's the same
issue (if you think otherwise, shout, and I'll open a new bug).
Differences: i686 and i686smp; HP Scanjet 5370c; FC5 (update bug version to FC5
as FC4 is on its way out?)
The same error occurs on: a PC running kernel-2.6.17-1.2174_FC5 with VIA USB
controllers; another with kernel-smp-2.6.17-1.2174_FC5 with Intel USB
controllers; and a laptop running kernel-2.6.17-1.2142_FC4 with Intel controllers.
I also note that it only occurs with uhci_hcd. Although the scanner is USB "1",
if I plug it into a USB2 hub so it's controlled by echi_hcd the error doesn't occur.
If I modprobe out ehci, forcing the same hub to use uhci, the error re-occurs.
I also have a stack of old kernels on that FC4 laptop - I'll see if I can nail
down when it broke. It is definitely occurring with kernel-2.6.15-1.2054_FC5.
The error was introduced between 2.6.15-1.1833_FC4 and 2.6.16-1.2069_FC4.
The earlier kernel does not exhibit the error; furthermore the "configuration #1
chosen from 1 choice" message is not output by the earlier kernel, but is by the
latter (promptly followed by the error).
For reference, to avoid confusing two separate bugs:
Even if a user overcomes the kernel/USB problems with the Scanjet 5300/5370C
such that it's recognised by scanimage -L, scanning using sane will fail and put
the scanner in an unusable state. This is fixed in sane-backends-1.0.18, which
ships in FC6. See bug 205092.
Stefan: I've double checked, and I'm definitely _not_ getting the "can't set
config #1, error -71" message with kernel-2.6.15-1.1833_FC4 (also
kernel-2.6.15-1.1831_FC4, kernel-2.6.15-1.1830_FC4). I do see it with
This conflicts with your report in comment 2 - are you sure that 2.6.15 produces
the "can't set config" and it wasn't bug 205092 that prevented the scanner from
working in this case?
You also say "problem appears regardless of what port it is plugged in or how it's
connected (directly / through a hub)" - was the hub you tried USB2? Because I
don't see the message when the scanner's controlled by ehci.
Don't forget to attach /proc/bus/usb/devices when you test, with a small
note "does work" or "does not work" and the log snippet. This is because
the hub may have TT (Transaction Translator) muddying the waters.
The file shows precisely which is plugged where and what HC drives what.
I am also seeing this bug with the scanner (error 71 and all), running kernel
2.6.17-1.2145_FC5 on x86_64. Can you really have a USB1 device be handled by the
ehci driver? Because when a USB1 device is plugged in, it is automatically
connected to the USB1 controller, which is controlled by the uhci_hcd driver.
Only USB2 devices get connected to the USB2 controller.
The scanner, when working, is definitely controlled by ehci - so, as Pete says,
the hub must have a Transaction Translator (possibly obscuring the root issue
from ehci?). Unfortunately I don't have physical access to the scanner any more
- I didn't get the chance to debug any further before it had to be shipped off
(and the USB2 hub circumvents the problem for me anyway). I'll try to arrange
for someone to plug it into a machine I have remote access on next week and
catpure some usbmon output if no-one else gets around to it beforehand.
To be clear: I don't see the error with any kernel when using a USB2 hub.
Without the hub (direct to uhci) I suffer it on all kernels from 2.6.16 onwards.
The scanner is not a USB2 device.
I see the error regardless of using a USB2 hub or not as stated above (retested).
[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
Please retest with Fedora Core 5.
Confirming the bug exists with FC5 as previously confirmed by other people.
Created attachment 138018 [details]
/proc/bus/usb/devices without hub (doesn't work)
see also usbmon without hub (doesn't work)
Created attachment 138019 [details]
usbmon without hub (doesn't work)
This is the usbmon output when plugging the scanner in - it fails with the
"can't set config" error.
The scanner is connected directly to the PC, and attaches using uhci_hcd.
See also /proc/bus/usb/devices without hub.
Created attachment 138020 [details]
/proc/bus/usb/devices with USB2 hub (works)
See also usbmon with USB2 hub (works)
Created attachment 138021 [details]
usbmon with USB2 hub (works)
This is the usbmon output when plugging the scanner in and it attached
The scanner is connected through a USB2 hub, and attaches using ehci_hcd.
See also /proc/bus/usb/devices with USB2 hub.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
Just tested it on 2.6.18-1.2200.fc5 and confirmed that the bug is still there.
The error messages are unchanged since the 2.6.17 series.
Confirmed that the problem still occurs, as before, with 2.6.18-1.2200.fc5
Still present in 2.6.18-1.2869.fc6.
Could owner update the bug to FC6, please?
This would appear to be a regression from 2.6.16 onwards. There is a fix:
but this backs out changes which make some "bar-scan readers" work.
More details (and a more elaborate patch with a module option) in the above
mandriva bug report; further discussion at:
I tried applying the simple patch to 2.6.18-1.2869.fc6 and it fixes the problem
I've otherwise been overcoming through use of a USB2 hub (however I'm still
stuck with Bug 206094).
From a brief browse of the kernel source, it looks like the patch mentioned:
made it into the mainline kernel.
I don't have physical access to the scanner to test it at the moment (and
probably won't until the new year) - sorry.
Kevin, are you on F8 now? That surely ought to work... I hope, at least.
Yes, F8 now. I had one final try with the scanner at the end of last year, and
I'm pretty sure the USB problems described here were fixed. I can test for sure
in a month or so if that helps.
Unfortunately the scanner in question has been retired due to ongoing
incompatibility with recent versions of SANE which I was unable to resolve
upstream, despite months of trying (bug #206094; no archive of the sane-avision
list annoyingly). Sorry to say I gave up :(
Thanks for letting me know. I'll close at least for now.