The 'Neodio Technologies Corp. 7-in-1 Card Reader' doesn't work with the 'ehci_hcd' kernel module, I found these messages in the log file Mar 10 20:09:47 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 4 Mar 10 20:09:47 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 8 Mar 10 20:09:48 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 10 Mar 10 20:09:48 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 12 ..... Mar 10 20:10:10 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 120 Mar 10 20:10:10 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 122 Mar 10 20:10:11 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 127 Mar 10 20:10:12 odo kernel: usb 5-4: new high speed USB device using ehci_hcd and address 5 and then it starts again. As you can see the ehci_hcd module creates 2 messages every second and fills the log file with these messages... I removed the ehci_hcd module and used only the standard usb module and then the card reader works but when I do a 'modprobe ehci_hcd' the card read fails again with the same messages. The problem is that I need the ehci_hcd module because of other device on the same USB bus and I can't remove the card read, because it's build into the system. This is the output from lsusb: Bus 002 Device 003: ID 0aec:3260 Neodio Technologies Corp. 7-in-1 Card Reader Kernel is 'kernel-2.6.24.3-12.fc8' and this is the output from lspci: 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1) 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01) 0b:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
May I have a usbmon trace for this? /usr/share/doc/kernel-doc-2.6.24/Documentation/usb/usbmon.txt
Created attachment 297510 [details] usbmon output This is the output from usbmon, I used cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out to create the output.
Please attach /proc/bus/usb/devices too, I want to know what the bus 1 is. Since we're at it, I'd like to see an unedited output of dmesg as well (best if it's taken early enough after reboot that before dmesg buffer overflows with all the cycling). If I read usbmon trace right, status 01050000 is _not_ a high-speed, so EHCI should not be driving this device at all. Also 00400000 is the suspend status. But I thought we disabled auto-suspend in F8. At first I thought it was a fallback fodder but now I'll need to look closer at this bug.
Created attachment 297528 [details] dmesg output
Created attachment 297529 [details] usb devices
The device is a card reader (for Compact Flash, Smartmedia, etc.) so I guess it should be high-speed USB but I can't tell you for sure because I can't use it on the high-speed bus :-)
Yes, I was wrong about the port status -- became confused by the byte order. The port senses a high-speed device. Here's one full loop: hub_port_init() --> hub_port_disable() on error ffff81002b449180 671307754 S Co:1:001:0 s 23 01 0001 0004 0000 0 <--- clear enable ffff81002b449180 671307757 C Co:1:001:0 0 0 hub_port_connect_change() --> hub_port_disable() on error ffff81002b449180 671307764 S Co:1:001:0 s 23 01 0001 0004 0000 0 ffff81002b449180 671307767 C Co:1:001:0 0 0 hub_port_connect_change() ---> hub_port_debounce() ffff81002b449180 671307772 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671307774 C Ci:1:001:0 0 4 = 00010000 0, PWR(1) ffff81003e0e4d80 671311682 C Ii:1:001:1 0:2048 2 = 1000 ffff81003e0e4d80 671311685 S Ii:1:001:1 -115:2048 4 < ffff81002b449180 671311720 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671311724 C Ci:1:001:0 0 4 = 01050100 CONN(1), HI(4)|PWR(1), C_CONN(1) ffff81002b449180 671311727 S Co:1:001:0 s 23 01 0010 0004 0000 0 <--- clear c_conn ffff81002b449180 671311735 C Co:1:001:0 0 0 ffff81002b449180 671311738 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671311740 C Ci:1:001:0 0 4 = 01050000 CONN(1), HI(4)|PWR(1) ffff81002b449180 671337484 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671337487 C Ci:1:001:0 0 4 = 01050000 ffff81002b449180 671363486 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671363490 C Ci:1:001:0 0 4 = 01050000 ffff81002b449180 671389484 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671389487 C Ci:1:001:0 0 4 = 01050000 ffff81002b449180 671415485 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671415489 C Ci:1:001:0 0 4 = 01050000 hub_port_connect_chage() -- > hub_port_init() ---> hub_port_reset() ffff81002b449180 671415498 S Co:1:001:0 s 23 03 0004 0004 0000 0 <--- set reset ffff81002b449180 671415501 C Co:1:001:0 0 0 ffff81002b449180 671466486 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81003e0e4d80 671466751 C Ii:1:001:1 0:2048 2 = 1000 ffff81003e0e4d80 671466754 S Ii:1:001:1 -115:2048 4 < ffff81002b449180 671466760 C Ci:1:001:0 0 4 = 03051000 CONN(1)|ENB(2), HI(4)|PWR(1), C_RST(10) ffff81002b449180 671517484 S Co:1:001:0 s 23 01 0014 0004 0000 0 <--- clear C_RESET ffff81002b449180 671517488 C Co:1:001:0 0 0 return to hub_port_init() ffff81002b449180 671517502 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < ffff81002b449180 671518109 C Ci:1:000:0 -71 0 ffff81002b449180 671518136 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < ffff81002b449180 671518858 C Ci:1:000:0 -71 0 ffff81002b449180 671518881 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < ffff81002b449180 671519607 C Ci:1:000:0 -71 0 ffff81002b449180 671519632 S Co:1:001:0 s 23 03 0004 0004 0000 0 <--- set reset ffff81002b449180 671519637 C Co:1:001:0 0 0 ffff81002b449180 671570487 S Ci:1:001:0 s a3 00 0000 0004 0004 4 < ffff81002b449180 671570727 C Ci:1:001:0 0 4 = 03051100 CONN(1)|ENB(2), HI(4)|PWR(1), C_RST(10)|C_CONN(1) ffff81002b449180 671570739 S Co:1:001:0 s 23 01 0014 0004 0000 0 <--- clear C_RST ffff81002b449180 671570743 C Co:1:001:0 0 0 ffff81002b449180 671570745 S Co:1:001:0 s 23 01 0001 0004 0000 0 <--- clear ENB ffff81002b449180 671570748 C Co:1:001:0 0 0 Basically everything looks good, we debounce, then reset and then try to read descriptors and get a solid -71. Seems like a prime candidate for the fallback code which Linux has coming online in 2.6.25. JM, can you boot a Rawhide kernel on this box? We have 2.6.25-0.90.rc3.git5.fc9 there, which supposedly has the fallback.
Yes, I can boot a Rawhide kernel on this system, where can I download the 2.6.25-0.90.rc3.git5.fc9 kernel?
I usually reach for the main site. It's slow, but it works: http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/Packages/
I tried the kernel '2.6.25-0.101.rc4.git3.fc9' because I couldn't find the '2.6.25-0.90.rc3.git5.fc9' version. I installed the kernel with the -nodeps option because the kernel needs also a new mkinitrd which needs several other RPMs as well and I don't want to mess up the whole system. I tried to boot the system with the 2.6.25-0.101.rc4.git3.fc9 kernel but the system fails to boot it looks like it can't mount something but during the boot process I get exactly the same messages about the card reader, actually when the system stops to boot all I can see on the screen is the message 'new high speed USB device using ehci_hcd and address 4' (etc.) because it fills up the whole screen. Is there anything else I can try? If you have other ideas, please let me know :-).
If it is not possible to fix this problems is there at least an option so that the ehci_hcd module ignores a certain device? For example as an option in /etc/modprobe.conf? It would help me a lot if the ehci_hcd module wouldn't touch the card reader at all :-).
No, there's no option. Since we cannot get any descriptors, we cannot address the device by its IDs. And the geographical addressing on USB is not stable, so we cannot use bus numbers and port numbers. Something is broken with the fallback or is outside of its parameters. I'll have to build you a test kernel with better printouts.
Mental note: fallback commit URL: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=90da096ee46b682011b7d549e52b81cf9742e60b
Just let me know when you have a kernel which I can use for testing, actually we have several system with identical hardware and all have the same problem with the USB card reader, so I would be really happy if you could find a way (no matter how :-)) to fix this problem. In the past I disconnected the USB card reader so that the system doesn't generate the messages but the cables to the reader are deep inside a "space optimized" case and therefore not easy to reach.
Is there anything new about this bug? I have the same problem but with all my USB2 devices(4xHDD, external DVD). Testet with the FC8 default kernel and the 2.6.24.4-64.fc8 on a Thinkpad T40p. Reproduce: * Plugin USB2 device * watch /var/log/messages ... kernel: usb 5-4: new high speed USB device using ehci_hcd and address XX ... Workaround: * rmmod ehci_hcd -> everthing works fine [root@localhost ~]# lspci 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) 02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
Nope, there's nothing new on my end. My own hardware does not reproduce it. However, I watch this bug closely and also talk with Ubuntu people, they have a stack of similar issues. The main problem is how intricate EHCI hardware is, so it takes a serious investigation, building special instrumented kernels. Eventually I'll have to come up with something (that is unless Alan Stern and David Brownell do it first). Here's the Launchpad URL: https://bugs.launchpad.net/ubuntu/+bug/88746 Note how there's a whole bunch of different reports there and it's hard to make sense of the problem. We're not at that point of noise in this bug yet.
kernel-2.6.24.7-92.fc8 still has the same problem.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.