Bug 436849

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.