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 lsusb shows: 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 How reproducible: Always Steps to Reproduce: 1. Plug in scanner into any USB port (with or without using a hub inbetween) 2. 3. Actual results: Scanner doesn't work at all Expected results: Scanner should work. Additional info: 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 : bmAttributes 0x40 Self Powered MaxPower 100mA 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: kernel-2.6.11-1.1369_FC4 kernel-2.6.16-1.21{08,11,15}_FC4 kernel-2.6.17-1.21{39,41,42}_FC4 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: /usr/share/doc/kernel-2.6.17/Documentation/usb/usbmon.txt 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 kernel-2.6.16-1.2069_FC4. 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 to FC5. Please retest with Fedora Core 5. Thank you.
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. Kernel 2.6.17-1.2187_FC5 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 successfully. The scanner is connected through a USB2 hub, and attaches using ehci_hcd. Kernel 2.6.17-1.2187_FC5 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. Thank you.
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: http://qa.mandriva.com/show_bug.cgi?id=26728#c7 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: http://bugzilla.kernel.org/show_bug.cgi?id=7436 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: http://bugzilla.kernel.org/show_bug.cgi?id=7436#c10 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.