Bug 8535

Summary: USB input death then system freeze
Product: Drivers Reporter: Nicolas Mailhot (Nicolas.Mailhot)
Component: Input DevicesAssignee: Andrew Morton (akpm)
Status: CLOSED CODE_FIX    
Severity: normal CC: clameter, davej, drivers_input-devices, greg, jikos, selinux, stern, stuart_hayes, zaitcev
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: Post 2.6.22 mm kernels, 2.6.23-rc0-git6 Subsystem:
Regression: --- Bisected commit-id:
Attachments: kernel config
Xorg logs
xorg conf
kernel logs
lsusb
lspci
Kernel logs with usb debug
'usbmon' run ("cat /sys/kernel/debug/usbmon/5u")
cat /sys/kernel/debug/usbmon/5u > /tmp/usbmon-5u.2
/var/log/messages showing BUGs, INFOs, etc.
Output of 'cat /sys/kernel/debug/usbmon/5u
'tar cf usb_host5.tar /sys/class/usb_host/usb_host5': mouse dead->mouse reinserted
'usbmon' run ("cat /sys/kernel/debug/usbmon/5u") for above 'run'
dmesg output showing borkage when 'lost' USB mouse is removed.
tar of usb_host5
proposed patch for ehci cpufreq issue with nvidia controllers
Slightly modified patch for Fedora 2.6.23-0.61.rc1.git9

Description Nicolas Mailhot 2007-05-24 11:02:48 UTC
Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm kernels, non-mm
2.6.22-rc2
Distribution: Fedora Devel
Hardware Environment: EHCI input on external powered hub with CK804 mainboard
Software Environment: Nothing specific
Problem Description:

After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB
HID INPUT (keyboard or mice with no priority), then the system will freeze

If the mouse/tackball is lost first switching to the console and moving the ball
will output random text. Restarting gpm will rescue the mouse (but the system
will lock up soon after anyway)

Same system with similar config works fine with mainline or older mm kernels

Last trace capture in logs before lockup:

Kernel:
drivers/hid/usbhid/hid-core.c: input irq status -75 received

Xorg:
ProcXCloseDevice to close or not ?
ProcXCloseDevice to close or not ?
(II) nek4k-enhanced-usb-0000:00:02.1-8.1/input1: Off
(II) track-expl-usb-0000:00:02.1-8.3/input0: Off


Steps to reproduce:
Just run the system for some time
Comment 1 Nicolas Mailhot 2007-05-24 11:03:39 UTC
Created attachment 11585 [details]
kernel config
Comment 2 Nicolas Mailhot 2007-05-24 11:11:10 UTC
Created attachment 11586 [details]
Xorg logs
Comment 3 Nicolas Mailhot 2007-05-24 11:11:56 UTC
Created attachment 11587 [details]
xorg conf
Comment 4 Nicolas Mailhot 2007-05-24 11:16:52 UTC
Created attachment 11588 [details]
kernel logs
Comment 5 Nicolas Mailhot 2007-05-24 11:19:21 UTC
Created attachment 11589 [details]
lsusb
Comment 6 Nicolas Mailhot 2007-05-24 11:19:58 UTC
Created attachment 11590 [details]
lspci
Comment 7 Adrian Bunk 2007-05-24 11:20:21 UTC
*** Bug 8534 has been marked as a duplicate of this bug. ***
Comment 8 Alan Stern 2007-05-24 13:29:55 UTC
Can you duplicate this with CONFIG_USB_DEBUG turned on?  It would help also to
see a usbmon trace of an incident.  Follow the instructions in the kernel source
file Documentation/usb/usbmon.txt.
Comment 9 Jiri Kosina 2007-05-24 14:18:46 UTC
There are really only a few minor patches in HID area between 2.6.22-rc2 and
2.6.22-rc2-mm2, I'd be surprised that they could be causing what you see, they
are basically just adding some quirks which apply to only a few hardware.

But just to make sure - could you please revert git-hid.patch and report if you
still can reproduce the problem? Thanks.
Comment 10 Nicolas Mailhot 2007-05-24 15:12:03 UTC
Ok

Will try all this friday evening or next tuesday (bed calls now, and we've got a
3-day weekend)

To be honest I first dismissed this as a fluke and hoped the newt mm would just
fix it. But it's happened several times already, and never on mainline
Comment 11 Jiri Kosina 2007-05-25 02:56:33 UTC
Report received from Zan Lynx:

drivers/hid/hid-core.c: report (size 3) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 3) =  00 00 00
hid-debug: input Keyboard.00e0 = 0
hid-debug: input Keyboard.00e1 = 0
hid-debug: input Keyboard.00e2 = 0
hid-debug: input Keyboard.00e3 = 0
hid-debug: input Keyboard.00e4 = 0
hid-debug: input Keyboard.00e5 = 0
hid-debug: input Keyboard.00e6 = 0
hid-debug: input Keyboard.00e7 = 0
drivers/hid/hid-core.c: report (size 4294967284) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 4294967284) =
hid-debug: input Keyboard.00e0 = 0
hid-debug: input Keyboard.00e1 = 0
hid-debug: input Keyboard.00e2 = 0
hid-debug: input Keyboard.00e3 = 0
hid-debug: input Keyboard.00e4 = 0
hid-debug: input Keyboard.00e5 = 0
hid-debug: input Keyboard.00e6 = 0
hid-debug: input Keyboard.00e7 = 0
drivers/hid/hid-core.c: report (size 6) (numbered)
drivers/hid/hid-core.c: report 2 (size 5) =  00 00 00 00 00
hid-debug: input Button.0001 = 0
hid-debug: input Button.0002 = 0
hid-debug: input Button.0003 = 0
hid-debug: input Button.0004 = 0
hid-debug: input Button.0005 = 0
hid-debug: input Button.0006 = 0
hid-debug: input Button.0007 = 0
hid-debug: input Button.0008 = 0
hid-debug: input GenericDesktop.X = 0
hid-debug: input GenericDesktop.Y = 0
hid-debug: input GenericDesktop.Wheel = 0
Hangcheck: hangcheck value past margin!
drivers/hid/usbhid/hid-core.c: input irq status -75 received


i.e. it seems that we are being passed URB with urb->actual_length == 4294967284
from USB core.
Comment 12 Nicolas Mailhot 2007-05-25 09:35:10 UTC
Jiri, do you want me to revert git-hid.patch or try CONFIG_USB_DEBUG + usbmon first?
Comment 13 Jiri Kosina 2007-05-26 07:01:07 UTC
It's be great if you would have time to test in this order:

- check whether it is reproducible without CONFIG_HIDRAW
- check whether it is reproducible with git-hid.patch reverted
- if it is still reproducible, then there is something wrong in usb core, so
we'd definitely need the usbmon traces and let someone (Alan, Greg, Oliver, etc)
to try to check usb core patches

Thanks a lot
Comment 14 Nicolas Mailhot 2007-05-26 07:46:01 UTC
Ok, I'll do this.
So far I've only added USB_DEBUG + usbmon

I had a mouse dead event but it was not followed by the usual keyboard+system
death. So I supposed it's somewhere in my usbmon logs but since it's not
timestamped I don't known where (25M of usbmon logs so far)

Do you want the USBMON logs by PM anyway ?

I'll rebuild a kernel without CONFIG_HIDRAW now (a pity, I suppose CONFIG_HIDRAW
is responsible for my keyboard MM keys working)
Comment 15 Nicolas Mailhot 2007-05-26 11:36:48 UTC
Created attachment 11601 [details]
Kernel logs with usb debug

Here are new logs with USB_DEBUG on as demanded by Alan Stern
The usbmon trace is too big I'll try to send it by PM
Mouse was lost several times (restored by switching to the console and
restarting gpm, which killed X), the last time followed by a system freeze

I'm testing without CONFIG_HIDRAW now
Comment 16 Nicolas Mailhot 2007-05-27 01:11:24 UTC
I've been greeted with a keyboard death this morning, which sort of answers if
the bug happens without CONFIG_HIDRAW

usb 2-8.3: unlink qh8-1c02/ffff810005ad6780 start 7 [1/2 us]

Next step on Jiri's list is to try with git-hid.patch reverted
Comment 17 Jiri Kosina 2007-05-27 08:16:34 UTC
Thanks a lot for your effort.

Just out of curiosity - do you have any other USB devices, or are the HID
keyboard and mice the only ones connected to the system?

Please let me know how's the situation with git-hid reverted. Thanks a lot.
Comment 18 Nicolas Mailhot 2007-05-27 16:36:05 UTC
There is a webcam that is connected but never used (gift, waits for a driver in
mainline), a dangling harmony cable waiting for Logitech Linux support, and
various stuff (smartmedia reader, ipod, X5) with is only connected for short
periods of times every other week. And definitely never on the problem kernels

Comment 19 Nicolas Mailhot 2007-05-28 08:00:52 UTC
Ok, just had an incident with git-hid.patch reverted
3 min from boot to system death that must be a record

16:36:57 Linux version 2.6.22-0.9.rc2.mm1.cfs14.fc8.nim
(mockbuild@rousalka.dyndns.org) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12))
#1 SMP PREEMPT Sun May 27 05:26:42 EDT 2007
[
Comment 20 Jiri Kosina 2007-05-28 09:07:09 UTC
OK, so we have ruled out HID-related changes completely. I'd bet this is related
to USB core, so let's see if Alan comes with any proposal (in the meantime I'll
go through USB-related patches in -mm and see whether I'll be able to spot
something alarming).

I have been trying to reproduce the hang with your .config, but the kernel
panics upon bootup, seems related to some sysfs stuff, I'll debug this separately.

I have also looked at the other report of the very same problem, and it seems
that both of you have SLUB turned on. Could you please try going back to SLAB
instead? It could be that we are getting some corruption of urb->actual_length
somewhere, some SLUB race might be at fault (I'd be quite surprised if it
affects only this one specific case, though).

Thanks a lot for your testing effort!
Comment 21 Nicolas Mailhot 2007-05-28 09:21:40 UTC
Adding Christoph Lameter if you think it's SLUB-related

Note that I use almost the same kernel config on mainline, and it has slub on
too. Also I did quite a lot of SLUB testing on pre-2.6.22 mm kernel and hit
stuff but not this one.

Lastly since the bug takes variable time to trigger (sometimes minutes sometimes
hours, even days) I should perhaps test again mainline. I've never hit it there
but maybe I just didn't run it long enough and was lucky.
Comment 22 Alan Stern 2007-05-28 09:52:26 UTC
So far I've looked at only one of your usbmon logs, the short one without
CONFIG_HIDRAW.  It didn't contain any errors at all, which wasn't much help.

All those link and unlink messages from ehci-hcd are strange; I would expect to
see messages from usbhid along with them.  The really intriguing messages are
the -75 errors; that's what I was hoping to see in the usbmon log.  Maybe some
will show up in the 3 MB file.

One possible source of problems is the fact that your keyboard and mouse are
non-high-speed devices running from a high-speed controller.  You might try
doing "rmmod ehci-hcd", forcing the full-speed controller will be used instead.
 If you do, do the hangs still occur?

Another thing to worry about is CONFIG_USB_EHCI_TT_NEWSCHED.  It's still a
little experimental.  You can try turning it off to see what happens.
Comment 23 Nicolas Mailhot 2007-05-28 10:22:12 UTC
Keyboard & mice are not connected directly but through a hub (used to be a
standalone high-speed one, now it's integrated in the monitor and I don't know
its capabilities)

I'll try:
1. without SLUB
2. without ehci
3. without CONFIG_USB_EHCI_TT_NEWSCHED.

All are enabled on mainline kernels where I don't have the problem (and IIRC
they were enabled on pre-2.6.22 mm kernels too) 
Comment 24 Alan Stern 2007-05-28 13:32:35 UTC
If possible, I'd like to see a usbmon trace covering the period when you get one
of those "input irq status -75 received" messages.

BTW, the integrated hub's capabilities are listed in your USB_DEBUG kernel log.
 Search through the log file for the string "2-8:1.0".  And for some unclear
reason, the mouse describes itself (in its Product string) as a Trackball.
Comment 25 Zan Lynx 2007-05-30 18:34:57 UTC
I tried some more tests on my laptop with this bug today.

The bug seems related to using a USB hub.  I believe this because when I plugged
the device directly into the laptop it worked for many hours, and is still
working as I type now.

USB_DEBUG gives this about the hub (snippet from a bugged session):
May 30 15:11:21 localhost kernel: PM: Adding info for usb:2-2
May 30 15:11:21 localhost kernel: usb 2-2: uevent
May 30 15:11:21 localhost kernel: usb 2-2: usb_probe_device
May 30 15:11:21 localhost kernel: PM: Adding info for No Bus:usbdev2.2_ep00
May 30 15:11:21 localhost kernel: usb 2-2: configuration #1 chosen from 1 choice
May 30 15:11:21 localhost kernel: usb 2-2: adding 2-2:1.0 (config #1, interface 0)
May 30 15:11:21 localhost kernel: PM: Adding info for usb:2-2:1.0
May 30 15:11:21 localhost kernel: usb 2-2:1.0: uevent
May 30 15:11:21 localhost kernel: usb 2-2:1.0: uevent
May 30 15:11:21 localhost kernel: hub 2-2:1.0: usb_probe_interface
May 30 15:11:21 localhost kernel: hub 2-2:1.0: usb_probe_interface - got id
May 30 15:11:21 localhost kernel: hub 2-2:1.0: USB hub found
May 30 15:11:21 localhost kernel: hub 2-2:1.0: 7 ports detected
May 30 15:11:21 localhost kernel: hub 2-2:1.0: standalone hub
May 30 15:11:21 localhost kernel: hub 2-2:1.0: ganged power switching
May 30 15:11:21 localhost kernel: hub 2-2:1.0: global over-current protection
May 30 15:11:21 localhost kernel: PM: Adding info for No Bus:usbdev2.2_ep81
May 30 15:11:21 localhost kernel: hub 2-2:1.0: TT per port
May 30 15:11:21 localhost kernel: hub 2-2:1.0: TT requires at most 8 FS bit
times (666 ns)
May 30 15:11:21 localhost kernel: hub 2-2:1.0: power on to power good time: 100ms
May 30 15:11:21 localhost kernel: hub 2-2:1.0: local power source is good
May 30 15:11:21 localhost kernel: hub 2-2:1.0: no over-current condition exists
May 30 15:11:21 localhost kernel: hub 2-2:1.0: enabling power on all ports
May 30 15:11:21 localhost kernel: usb 2-2: link qh256-0001/ffff81000462d240
start 255 [1/0 us]
May 30 15:11:21 localhost kernel: drivers/usb/core/inode.c: creating file '002'
May 30 15:11:21 localhost kernel: hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0000
May 30 15:11:21 localhost kernel: hub 2-2:1.0: state 7 ports 7 chg 0000 evt 0000
May 30 15:11:21 localhost kernel: hub 2-2:1.0: port 1, status 0301, change 0001,
1.5 Mb/s
May 30 15:11:21 localhost kernel: hub 2-2:1.0: debounce: port 1: total 100ms
stable 100ms status 0x301
May 30 15:11:21 localhost kernel: hub 2-2:1.0: port 1 not reset yet, waiting 10ms
May 30 15:11:21 localhost kernel: usb 2-2.1: new low speed USB device using
ehci_hcd and address 3
May 30 15:11:21 localhost kernel: hub 2-2:1.0: port 1 not reset yet, waiting 10ms
May 30 15:11:21 localhost kernel: usb 2-2.1: skipped 1 descriptor after interface
May 30 15:11:21 localhost kernel: usb 2-2.1: default language 0x0409
May 30 15:11:21 localhost kernel: usb 2-2.1: new device found, idVendor=045e,
idProduct=0059
May 30 15:11:21 localhost kernel: usb 2-2.1: new device strings: Mfr=1,
Product=2, SerialNumber=0
May 30 15:11:21 localhost kernel: usb 2-2.1: Product: Microsoft Wireless
Intellimouse Explorer
Comment 26 Nicolas Mailhot 2007-07-18 12:12:45 UTC
The bug has now been merged in mainline, and affects post-2.6.22 fedora-devel kernels (kernel-2.6.23-0.28.rc0.git6.fc8.x86_64, kernel-2.6.23-0.29.rc0.git6.fc8.x86_64)

Jul 18 20:51:08 rousalka kernel: drivers/hid/usbhid/hid-core.c: input irq status
 -75 received
Comment 27 Alan Stern 2007-07-18 14:19:59 UTC
In itself a -75 error isn't a problem.  It means there was a communications failure, which can happen from time to time (especially with high-speed USB).

But if it causes a system crash then something really is wrong.  There's code in the usbhid driver to retry and recover from those errors; it should be running.

I'd still like to see a usbmon trace for a period including one of those -75 errors.
Comment 28 Pete Zaitcev 2007-07-21 14:17:13 UTC
The usbmon log should compress really well, up to 4 times or so. Is it 3MB
after bzip2 or before?
Comment 29 Nicolas Mailhot 2007-07-21 15:56:52 UTC
(In reply to comment #28)
> The usbmon log should compress really well, up to 4 times or so. Is it 3MB
> after bzip2 or before?

compressed with bzip2 at maximum level of compression IIRC. I've attached everything that fit under bugzilla's 1M lilit there
Comment 30 Alan Stern 2007-07-22 09:18:17 UTC
Attached it where?
Comment 31 Tom London 2007-07-22 09:21:08 UTC
Created attachment 12091 [details]
'usbmon' run ("cat /sys/kernel/debug/usbmon/5u")

Attached is a 'usbmon' run when 'my cursor got lost'.

System is a Thinkpad X60 running Fedora rawhide (kernel-PAE-2.6.23-0.43.rc0.git16.fc8).

System usually boots up, always 'losing' first character typed on usb keyboard and with cursor 'missing'.  Pulling out and reinserting cursor recovers cursor for a while.

I started this log with a functioning cursor, and killed the 'cat' after losing the cursor, pulling it out, and plugging it back in.

Hope this helps....

tom
Comment 32 Tom London 2007-07-22 11:23:36 UTC
Created attachment 12092 [details]
cat /sys/kernel/debug/usbmon/5u > /tmp/usbmon-5u.2

Here is another output from "cat /sys/kernel/debug/usbmon/5u > /tmp/usbmon-5u.2"

Here is output of 'lsusb':

[root@localhost tmp]# lsusb
Bus 5 Device 9: ID 0461:4d03 Primax Electronics, Ltd Kensington Mouse-in-a-box
Bus 5 Device 5: ID 05f3:0203 PI Engineering, Inc. 
Bus 5 Device 2: ID 17ef:1000  
Bus 5 Device 1: ID 0000:0000  
Bus 3 Device 1: ID 0000:0000  
Bus 4 Device 3: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 4 Device 2: ID 0a5c:2110 Broadcom Corp. 
Bus 4 Device 1: ID 0000:0000  
Bus 2 Device 1: ID 0000:0000  
Bus 1 Device 1: ID 0000:0000  
[root@localhost tmp]#
Comment 33 Alan Stern 2007-07-23 09:33:30 UTC
The log in comment #31 shows no errors, just an unplug and a replug.  The log in comment #32 does show one error:

   dff46c30 1863662787 C Ii:5:008:1 0:8 -4

This occurred 7 seconds before the unplug.  What type of USB controller do you have on bus 5?

And what is device 2 on bus 5?  Is it an external hub?  Or is it something built into the Kensington Mouse?
Comment 34 Tom London 2007-07-23 11:01:03 UTC
Device 2 on bus 5 is a USB mouse (says HP on the top, suspect Kensington makes it).

I'm running a Thinkpad X60, believe with ICH7:

[root@localhost Downloads]# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09)
15:00.2 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)
[root@localhost Downloads]# 

The mouse is connected directly into a Thinkpad 'dock'.
Comment 35 Tom London 2007-07-23 12:05:23 UTC
Created attachment 12108 [details]
/var/log/messages showing BUGs, INFOs, etc.

With latest Fedora kernel (kernel-PAE-2.6.23-0.45.rc0.git16.fc8), I now get a crash with log when I remove USB mouse (mouse was dead prior to removal).

Not sure its the same issue as above, but I'm posting it here for completeness.
Comment 36 Alan Stern 2007-07-23 15:15:38 UTC
In fact your Kensington Mouse was device 9 on bus 5.  Device 2 must be the dock's internal hub.  Maybe the dock is behaving strangely...  What does /proc/bus/usb/devices show?

The crash when you unplugged the mouse is a completely different issue.  If it continues for the next few kernel releases you should file a separate new bug report for it.
Comment 37 Tom London 2007-07-23 15:27:13 UTC
Sorry for the confusion.... I have 2 configurations: one @home, one @work.

The usbmon logs were both from the @home config.  The log in comment 35 is from the @work config.

Here is 'cat /proc/bus/usb/devices' from @work:  (I'll log the one from @home later tonight).  The dock behaves 'fine' with earlier kernels, btw.

[root@localhost ~]# cat $_

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  4, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=05 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  2 Spd=480 MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=17ef ProdID=1000 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=05 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=045e ProdID=0084 Rev= 0.00
S:  Manufacturer=Microsoft
S:  Product=Basic Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=10ms

T:  Bus=05 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#=  6 Spd=480 MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0409 ProdID=0058 Rev= 1.00
S:  Manufacturer=NEC Corporation
S:  Product=USB2.0 Hub Controller
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=05 Lev=03 Prnt=06 Port=01 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=03f0 ProdID=1017 Rev= 1.00
S:  Manufacturer=Hewlett-Packard
S:  Product=hp LaserJet 1300
S:  SerialNumber=00CNCB954325
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=07(print) Sub=01 Prot=03 Driver=usblp
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
I:* If#= 0 Alt= 1 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 0 Alt= 2 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=usblp
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=05 Lev=03 Prnt=06 Port=02 Cnt=02 Dev#=  8 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=413c ProdID=2005 Rev= 1.04
S:  Manufacturer=DELL
S:  Product=DELL USB Keyboard
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a5c ProdID=2110 Rev= 1.00
S:  Manufacturer=Broadcom Corp
S:  Product=BCM2045B
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  32 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  32 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)

T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0483 ProdID=2016 Rev= 0.01
S:  Manufacturer=STMicroelectronics
S:  Product=Biometric Coprocessor
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   4 Ivl=20ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
[root@localhost ~]# 
Comment 38 Tom London 2007-07-24 07:40:18 UTC
Created attachment 12118 [details]
Output of 'cat /sys/kernel/debug/usbmon/5u
Comment 39 Tom London 2007-07-24 07:43:32 UTC
(In reply to comment #38)
> Created an attachment (id=12118) [details]
> Output of 'cat /sys/kernel/debug/usbmon/5u
> 
Above attachment is another 'lost mouse and system froze a few minutes later'.

I'm 'standardizing' the setup as much as I can: same mouse in same USB socket in both my @home and @work setups.

Here is output of 'lsusb' from @home setup:

[root@localhost ~]# lsusb
Bus 5 Device 5: ID 05f3:0203 PI Engineering, Inc. 
Bus 5 Device 6: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 5 Device 2: ID 17ef:1000  
Bus 5 Device 1: ID 0000:0000  
Bus 4 Device 2: ID 0a5c:2110 Broadcom Corp. 
Bus 4 Device 3: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 4 Device 1: ID 0000:0000  
Bus 3 Device 1: ID 0000:0000  
Bus 2 Device 1: ID 0000:0000  
Bus 1 Device 1: ID 0000:0000  
[root@localhost ~]# 

Here is output of 'cat /proc/bus/usb/devices':

[root@localhost ~]# cat /proc/bus/usb/devices

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  4, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=05 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  2 Spd=480 MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=17ef ProdID=1000 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=05 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05f3 ProdID=0203 Rev= 1.20
S:  Manufacturer=P.I. Engineering
S:  Product=P� Keyboard/Mouse to USB 2dapter
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   4 Ivl=10ms

T:  Bus=05 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  6 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=045e ProdID=0040 Rev= 3.00
S:  Manufacturer=Microsoft
S:  Product=Microsoft 3-Button Mouse with IntelliEye(TM)
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=10ms

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a5c ProdID=2110 Rev= 1.00
S:  Manufacturer=Broadcom Corp
S:  Product=BCM2045B
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  32 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  32 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)

T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0483 ProdID=2016 Rev= 0.01
S:  Manufacturer=STMicroelectronics
S:  Product=Biometric Coprocessor
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   4 Ivl=20ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-0.15.rc0.git1.fc8PAE uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
[root@localhost ~]#

I can produce these pretty much 'at will'.  Let me know if you need more.....
Comment 40 Alan Stern 2007-07-24 08:21:13 UTC
Here's something to try.  First, make sure the CONFIG_USB_DEBUG is enabled in your kernel's configuration.  Then the next time you get a mouse freeze, make copies of the files in /sys/class/usb_host/usb_host5 and attach them to this bug report.
Comment 41 Tom London 2007-07-24 09:14:51 UTC
OK. Will need to get/make a Fedora kernel with CONFIG_USB_DEBUG enabled: currently not set.
Comment 42 stuart hayes 2007-07-24 14:41:29 UTC
I have a feeling that this might be caused by gregkh-usb-usb-ehci-cpufreq-fix.patch... this patch was an attempt to keep split-interrupt transactions from being run to low/full speed devices on the EHCI controller during cpu frequency transitions.

You problem seems to be with low/full speed devices on the EHCI controller, with exactly the version of the kernel when this patch was added, and you appear to have cpu_freq enabled and a processor that would use it...

Could you back this patch out and test?
Comment 43 Pete Zaitcev 2007-07-24 22:43:14 UTC
It may be easier to disable CONFIG_CPU_FREQ than finding the patch.

I looked all over the patch, and although it seems rather murky, it
also seems not doing anything wrong with the hw_token.

I figure that qtd->length somehow gets zeroed (by ehci_qtd_init
perhaps), or maybe qh token ends with bigger length than qtd here:
			if (state == QH_STATE_IDLE
					&& cpu_to_hc32(ehci, qtd->qtd_dma)
						== qh->hw_current)
				token = hc32_to_cpu(ehci, qh->hw_token);

But without having Nicolas' or Tom's hardware I cannot tinker with
it and find it.

BTW, Nicolas sent me his logs out of line, and he has the same thing
as Tom in comment #32 (Nicolas got an Opteron but otherwise same thing):

ffff8100057f6100 1435001203 S Ii:2:004:1 -115:8 4 <
ffff8100055ccc00 1436320906 C Ii:2:003:1 0:8 8 = 00000600 00000000
.......
ffff8100055ccc00 1467276116 S Ii:2:003:1 -115:8 8 <
ffff8100057f6100 1467276128 C Ii:2:004:1 0:8 -4
Comment 44 Tom London 2007-07-25 06:42:08 UTC
Thanks, I was struggling yesterday trying to find/undo the patch.

In any case, I built a version of Fedora Rawhide with USB_DEBUB set (kernel-2.6.23-0.44.tblv3.rc0.git16.fc8), and here is what I got on booting.

The situation was that the mouse was 'alive' during boot (with 'console mouse services'and gdmgreeter) but almost immediately 'dead' after entering password and rendering of gnome screen.

I pulled the mouse and reinserted.  Got this in /var/log/messages.

Is this useful?  I'll post the tar of /sys/class/usb_host/usb_host5 in the next message.

Need more?  Need me to disable CONFIG_CPU_FREQ?

Unless I hear otherwise, I'll attempt to build a CPU_FREQ-less kernel ...

tom


Jul 25 06:20:26 localhost kernel: hub 5-6:1.0: state 7 ports 4 chg 0000 evt 0008
Jul 25 06:20:26 localhost kernel: hub 5-6:1.0: port 3, status 0100, change 0001, 12 Mb/s
Jul 25 06:20:26 localhost kernel: usb 5-6.3: USB disconnect, address 6
Jul 25 06:20:26 localhost kernel: usb 5-6.3: unregistering device
Jul 25 06:20:26 localhost kernel: usb 5-6.3: usb_disable_device nuking all URBs
Jul 25 06:20:26 localhost kernel: usb 5-6.3: unlink qh8-0e01/f7a56460 start 7 [1/2 us]
Jul 25 06:20:26 localhost kernel: ehci_hcd 0000:00:1d.7: shutdown urb f7ebd870 pipe 40408680 ep1in-intr
Jul 25 06:20:26 localhost kernel: usb 5-6.3: unregistering interface 5-6.3:1.0
Jul 25 06:20:26 localhost kernel: usb_endpoint usbdev5.6_ep81: ep_device_release called for usbdev5.6_ep81
Jul 25 06:20:26 localhost kernel: usb 5-6.3:1.0: uevent
Jul 25 06:20:26 localhost kernel: usb 5-6.3:1.0: uevent
Jul 25 06:20:26 localhost kernel: usb_endpoint usbdev5.6_ep00: ep_device_release called for usbdev5.6_ep00
Jul 25 06:20:26 localhost kernel: usb 5-6.3: uevent
Jul 25 06:20:26 localhost kernel: hub 5-6:1.0: debounce: port 3: total 100ms stable 100ms status 0x100
Jul 25 06:20:30 localhost kernel: hub 5-6:1.0: state 7 ports 4 chg 0000 evt 0008
Jul 25 06:20:30 localhost kernel: hub 5-6:1.0: port 3, status 0301, change 0001, 1.5 Mb/s
Jul 25 06:20:30 localhost kernel: hub 5-6:1.0: debounce: port 3: total 100ms stable 100ms status 0x301
Jul 25 06:20:30 localhost kernel: hub 5-6:1.0: port 3 not reset yet, waiting 10ms
Jul 25 06:20:31 localhost kernel: usb 5-6.3: new low speed USB device using ehci_hcd and address 7
Jul 25 06:20:31 localhost kernel: hub 5-6:1.0: port 3 not reset yet, waiting 10ms
Jul 25 06:20:31 localhost kernel: usb 5-6.3: skipped 1 descriptor after interface
Jul 25 06:20:31 localhost kernel: usb 5-6.3: default language 0x0409
Jul 25 06:20:31 localhost kernel: usb 5-6.3: new device strings: Mfr=1, Product=3, SerialNumber=0
Jul 25 06:20:31 localhost kernel: usb 5-6.3: Product: Microsoft 3-Button Mouse with IntelliEye(TM)
Jul 25 06:20:31 localhost kernel: usb 5-6.3: Manufacturer: Microsoft
Jul 25 06:20:31 localhost kernel: usb 5-6.3: uevent
Jul 25 06:20:31 localhost kernel: usb 5-6.3: usb_probe_device
Jul 25 06:20:31 localhost kernel: usb 5-6.3: configuration #1 chosen from 1 choice
Jul 25 06:20:31 localhost kernel: usb 5-6.3: adding 5-6.3:1.0 (config #1, interface 0)
Jul 25 06:20:31 localhost kernel: usb 5-6.3:1.0: uevent
Jul 25 06:20:31 localhost kernel: usb 5-6.3:1.0: uevent
Jul 25 06:20:31 localhost kernel: usb 5-6.3:1.0: uevent
Jul 25 06:20:31 localhost kernel: usbhid 5-6.3:1.0: usb_probe_interface
Jul 25 06:20:31 localhost kernel: usbhid 5-6.3:1.0: usb_probe_interface - got id
Jul 25 06:20:31 localhost kernel: input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /class/input/input9
Jul 25 06:20:31 localhost kernel: usb 5-6.3: link qh8-0e01/f7a56460 start 7 [1/2 us]
Jul 25 06:20:31 localhost kernel: input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.7-6.3
Jul 25 06:20:31 localhost kernel: drivers/usb/core/inode.c: creating file '007'
Jul 25 06:20:55 localhost kernel: hub 5-6:1.0: state 7 ports 4 chg 0000 evt 0000
Comment 45 Tom London 2007-07-25 06:44:10 UTC
Created attachment 12135 [details]
'tar cf usb_host5.tar /sys/class/usb_host/usb_host5': mouse dead->mouse reinserted
Comment 46 Tom London 2007-07-25 07:28:26 UTC
Created attachment 12136 [details]
'usbmon' run ("cat /sys/kernel/debug/usbmon/5u") for above 'run'
Comment 47 Tom London 2007-07-25 09:17:35 UTC
OK.... I built a Fedora Rawhide kernel with USB_DEBUG enabled and CPU_FREQ disabled (kernel-2.6.23-0.44.tblv4.rc0.git16.fc8).

This system seems definitely happier: mouse and keyboard seem to come up 'working', I have not observed any 'lost keypresses', and the mouse has not 'dropped off the end of the earth'.

On the other hand, I'm clocking my laptop at maximum rate....

Any 'usbmon' info from this that would be useful?

What else can I do to help?
Comment 48 Alan Stern 2007-07-25 11:26:05 UTC
Are you sure you had the debugging version of the ehci-hcd driver loaded when you created the attachment in comment #45?  That directory should contain a bunch of files with names like "registers" and "async".  (And by the way, be careful to capture the file contents while the mouse is dead, before you unplug it.)

I don't think usbmon will be any use for the non-CPU_FREQ experiment.  Stuart will have to tell you how to debug that aspect.
Comment 49 Tom London 2007-07-25 14:02:43 UTC
No, not sure: I compiled kernel with 'CONFIG_USB_DEBUG', but perhaps I need to run tar with '--ignore-failed-read'.....

I do so next time.
Comment 50 Tom London 2007-07-25 15:29:12 UTC
This is harder than it appears.....

Looks like some of the files in /sys/class/usb_host/usb_host5 are all zeros.

Here is the scenario and what I did:

1. Booted with kernel built with CONFIG_USB_DEBUG.
2. When gdmgreeter came up, mouse was 'lost' (i.e. cursor on screen didn't move).
3. As per request in #48, I CTL-ALT-F1 to console, logged in as root.
4. I did a 'tar -cf usb_host5-2.tar --ignore-failed-read /sys/class/usb_host/usb_host5'
5. Here is output from running tar:

tar: Removing leading `/' from member names
tar: /sys/class/usb_host/usb_host5/companion: File shrank by 4096 bytes; padding with zeros
tar: /sys/class/usb_host/usb_host5/registers: File shrank by 3396 bytes; padding with zeros
tar: /sys/class/usb_host/usb_host5/periodic: File shrank by 728 bytes; padding with zeros
tar: /sys/class/usb_host/usb_host5/async: File shrank by 4096 bytes; padding with zeros
tar: /sys/class/usb_host/usb_host5/uevent: Warning: Cannot open: Permission denied

6. Here is 'ls -l /sys/class/usb_host/usb_host5':

total 0
-r--r--r-- 1 root root 4096 2007-07-25 15:00 async
-rw-r--r-- 1 root root 4096 2007-07-25 15:00 companion
lrwxrwxrwx 1 root root    0 2007-07-25 14:59 device -> ../../../devices/pci0000:00/0000:00:1d.7
-r--r--r-- 1 root root 4096 2007-07-25 15:00 periodic
-r--r--r-- 1 root root 4096 2007-07-25 15:00 registers
lrwxrwxrwx 1 root root    0 2007-07-25 14:59 subsystem -> ../../../class/usb_host
--w------- 1 root root 4096 2007-07-25 14:59 uevent

7. So, additional files in this directary are 'empty', and not included in tar file.

8. Pulling the plug on the mouse while still in this terminal produced lots of spew, starting with:

hub 5-6:1.0: state 7 ports 4 chg 0000 evt 0008
hub 5-6:1.0: port 3, status 0100, change 0001, 12 Mb/s
usb 5-6.3: USB disconnect, address 6
usb 5-6.3: unregistering device
usb 5-6.3: usb_disable_device nuking all URBs
usb 5-6.3: unlink qh8-0e01/dfc855a0 start 7 [1/2 us]
ehci_hcd 0000:00:1d.7: shutdown urb f7ef32d0 pipe 40408680 ep1in-intr
usb 5-6.3: unregistering interface 5-6.3:1.0
usb_endpoint usbdev5.6_ep81: ep_device_release called for usbdev5.6_ep81
=============================================================================
BUG sysfs_dir_cache (Not tainted): Padding overwritten. 0x64646150-0x20676e69
-----------------------------------------------------------------------------

INFO: Slab 0xc1c3c5d0 used=42 fp=0x00000000 flags=0x40000083
 [<c04062b1>] show_trace_log_lvl+0x1a/0x2f
 [<c0406d4a>] show_trace+0x12/0x14
 [<c0406d62>] dump_stack+0x16/0x18
 [<c0484896>] slab_err+0x3e/0x44
 [<c0484927>] slab_pad_check+0x8b/0xc6
 [<c04849fa>] check_slab+0x98/0xa4
 [<c0485623>] __slab_free+0xbd/0x251
 [<c0485da9>] kmem_cache_free+0x8a/0xbe
 [<c04c4b75>] release_sysfs_dirent+0x6e/0x83
 [<c04c4d98>] sysfs_addrm_finish+0x1dd/0x1f6
 [<c04c3ac2>] sysfs_hash_and_remove+0x52/0x7f
 [<c04c41bf>] sysfs_remove_file+0xd/0xf
 [<c057160c>] device_remove_file+0x1f/0x2a
 [<c0571883>] device_del+0x204/0x288
 [<c058b517>] usb_disable_device+0xdf/0x142
 [<c0586d6e>] usb_disconnect+0xd3/0x16c
 [<c058819a>] hub_thread+0x64d/0xeb4
 [<c043e360>] kthread+0x3b/0x63
 [<c0405d53>] kernel_thread_helper+0x7/0x10
 =======================

and ending with:

BUG: unable to handle kernel paging request at virtual address 5a5a5a76
 printing eip:
c04c3a90
*pde = 00000000
Oops: 0000 [#1]
SMP 
Modules linked in: i915 drm netconsole ipv6 nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables cpufreq_ondemand acpi_cpufreq dm_multipath video sbs button bay dock battery ac kvm_intel kvm sr_mod cdrom snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq hci_usb firewire_ohci snd_seq_device irda bluetooth snd_pcm_oss snd_mixer_oss e1000 parport_pc snd_pcm ata_piix parport firewire_core crc_ccitt crc_itu_t i2c_i801 usblp sdhci serio_raw rtc_cmos mmc_core snd_timer ata_generic i2c_core snd iTCO_wdt soundcore iTCO_vendor_support snd_page_alloc sg dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[<c04c3a90>]    Not tainted VLI
EFLAGS: 00010206   (2.6.23-0.44.tblv3.rc0.git16.fc8 #1)
EIP is at sysfs_hash_and_remove+0x20/0x7f
eax: f7ef6480   ebx: c06d90dc   ecx: f7ef6490   edx: 5a5a5a5a
esi: f7ef6480   edi: dfeae44c   ebp: c2e8be7c   esp: c2e8be60
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process khubd (pid: 204, ti=c2e8b000 task=c2ea6000 task.ti=c2e8b000)
Stack: f7ef6480 00000000 00000000 00000000 dfeae534 dfeae44c dfeae44c c2e8be84 
       c04c5bdb c2e8be94 c05731a8 dfeae430 dfeae44c c2e8beac c0571891 dfe070b8 
       dfeae430 dfe07060 dfeae44c c2e8bee0 c058b517 c06f01b0 c06f076e dfe071fc 
Call Trace:
 [<c04062b1>] show_trace_log_lvl+0x1a/0x2f
 [<c0406361>] show_stack_log_lvl+0x9b/0xa3
 [<c0406521>] show_registers+0x1b8/0x289
 [<c0406709>] die+0x117/0x24a
 [<c06318ac>] do_page_fault+0x492/0x563
 [<c06300da>] error_code+0x72/0x78
 [<c04c5bdb>] sysfs_remove_link+0xb/0xd
 [<c05731a8>] bus_remove_device+0x22/0x82
 [<c0571891>] device_del+0x212/0x288
 [<c058b517>] usb_disable_device+0xdf/0x142
 [<c0586d6e>] usb_disconnect+0xd3/0x16c
 [<c058819a>] hub_thread+0x64d/0xeb4
 [<c043e360>] kthread+0x3b/0x63
 [<c0405d53>] kernel_thread_helper+0x7/0x10
 =======================
Code: 14 89 d0 5b 5e 5f 5d c3 90 90 90 55 89 e5 57 56 89 c6 53 89 d3 83 ec 10 85 c0 74 5f 8d 45 e4 89 f2 e8 6f 0e 00 00 8d 4e 10 eb 24 <80> 7a 1c 00 74 19 8b 72 14 89 df ac ae 75 08 84 c0 75 f8 31 c0 
EIP: [<c04c3a90>] sysfs_hash_and_remove+0x20/0x7f SS:ESP 0068:c2e8be60

I tried to repeat this by rebooting, etc.  Followed exactly the same steps until this last one:  this time I got a hard panic with no sync.

I attach the complete dmesg output below.

Suggestions, please!
Comment 51 Tom London 2007-07-25 15:31:09 UTC
Created attachment 12141 [details]
dmesg output showing borkage when 'lost' USB mouse is removed.
Comment 52 Alan Stern 2007-07-26 07:33:09 UTC
Don't worry too much about that bug and crash; they are a completely separate issue.

Where's the tar file?
Comment 53 Tom London 2007-07-26 07:52:05 UTC
Created attachment 12157 [details]
tar of usb_host5

Here it is, but it looks just like the last one.

I just changed CONFIG_USB_DEBUG. Are there additional configs that need to be set as well?

Is there a different BZ that I should be filing the 'crash' to?

Also, another data point: my ThinkPad X60 'dock' has 4 USB jacks; the ThinkPad itself has 3 that are exposed when in the dock.

If I plug the mouse in any of the ports on the dock, the mouse gets connected via something like:
Jul 26 06:18:13 localhost kernel: usb 5-6.2: new low speed USB device using ehci_hcd and address 5

If I plug the mouse in any of the ports on the laptop (not the dock), the mouse gets connected with something like:
Jul 26 07:28:24 localhost kernel: usb 3-1: new low speed USB device using uhci_hcd and address 3

In this configuration, the system (latest Fedora Rawhide: kernel-PAE-2.6.23-0.47.rc1.git1.fc8) seems stable, and the mouse and keyboard seem just fine.
Comment 54 Alan Stern 2007-07-26 08:55:19 UTC
Never mind the tar archive.  The most important thing I wanted to check was the "async" file, and it looks like that one really did shrink down to nothing.  Besides, the fact that everything works without CPU_FREQ means that Stuart's trail is the correct one to follow.  He says that he has been able to reproduce symptoms similar to yours and he's trying to come up with a fix.

Don't worry about reporting the BUG; I have already notified the appropriate person.

The change in behavior according to whether you plug the mouse into the dock or directly into the computer is expected.  This particular problem manifests whenever a low- or full-speed device (like your mouse) is plugged into a high-speed hub (like the one in your dock).
Comment 55 Natalie Protasevich 2007-07-27 02:33:01 UTC
Note from Tejun Heo <htejun@gmail.com>:

    http://article.gmane.org/gmane.linux.kernel/556682/raw

    Does this patch fix the problem?

Please test, thanks.
Comment 56 stuart hayes 2007-07-27 08:59:19 UTC
I was able to reproduce these symptoms on a system with an nVidia EHCI controller, and I think I've found the problem.  The EHCI 1.0 spec, section 4.12.2.5, says...

"If the Active bit is a one and the SplitXState is DoStart (regardless of the value of S-mask), the host controller will simply set Active bit to a zero. The host controller is not required to write the transfer state back to the current qTD."

Apparently the Intel & Broadcom controllers *don't* write the transfer state back to the current qTD, but nVidia does... so, with nVidia, when the inactivate bit is set, the controller will set the active bit to 0 in the qTD, and then, when it is reactivated, my patch just sets the active bit back to 1 in the transfer overlay, not in the qTD... so the next time an IRQ comes in, qh_completions sees that the qtd isn't active and assumes it is finished, even though it isn't.

I believe the fix will be something like this.  It fixes the problem on my system, but I'm still looking to make sure I don't see any problems with it.


--- linux-2.6.22-rc1-mm1-orig/drivers/usb/host/ehci-sched.c.orig	2007-07-27 03:47:37.000000000 -0500
+++ linux-2.6.22-rc1-mm1-orig/drivers/usb/host/ehci-sched.c	2007-07-27 03:47:40.000000000 -0500
@@ -566,12 +566,15 @@ static void qh_reactivate_split_intr_qhs
 			if (safe == 0) {
 				not_done = 1;
 			} else if (safe > 0) {
+				struct ehci_qtd * qtd;
+				qtd = list_entry (qh->qtd_list.next, struct ehci_qtd, qtd_list);
 				/* See EHCI 1.0 section 4.15.2.4. */
 				token = qh->hw_token;
 				qh->hw_token = (token | HALT_BIT) & ~ACTIVE_BIT;
 				wmb();
 				qh->hw_info1 &= ~INACTIVATE_BIT;
 				wmb();
+				qtd->hw_token = (token & ~HALT_BIT) | qh->was_active;
 				qh->hw_token = (token & ~HALT_BIT) | qh->was_active;
 			}
 		}
Comment 57 stuart hayes 2007-07-30 11:25:52 UTC
Ok, I have a patch to fix this.  I'm still testing on a couple systems to make sure it's OK, but there isn't really much to it.

Which kernel should I make this patch against?  It applies on top of my previous patch, which is in the -mm kernel... should my patch be against the latest -mm kernel?

Thanks!
Comment 58 Alan Stern 2007-07-30 12:41:43 UTC
Post a patch against 2.6.23-rc1; that kernel has your other changes too.
Comment 59 stuart hayes 2007-07-31 14:37:40 UTC
Created attachment 12215 [details]
proposed patch for ehci cpufreq issue with nvidia controllers

This patch is against kernel 2.6.23-rc1.
Comment 60 stuart hayes 2007-07-31 14:42:56 UTC
I assume I need to send this patch separately to linux-usb-devel in the usual manner...?
Comment 61 Greg Kroah-Hartman 2007-07-31 14:52:42 UTC
On Tue, Jul 31, 2007 at 02:36:53PM -0700, bugme-daemon@bugzilla.kernel.org wrote:
> I assume I need to send this patch separately to linux-usb-devel in the usual
> manner...?

And be sure to CC: the usb maintainer so he doesn't miss it :)
Comment 62 Grant Likely 2007-07-31 17:11:15 UTC
Tested on MacBook Core2Duo against Linus' tree (2.6.23-rc1-g6c8dca5d).  Seems to solve issue for me.
Comment 63 Tom London 2007-08-01 11:36:57 UTC
Created attachment 12228 [details]
Slightly modified patch for Fedora 2.6.23-0.61.rc1.git9

The attached slightly modified patch 'works for me' with 2.6.23-0.61.rc1.git9 on Thinkpad X60.

This laptop does not have nVidia, but Intel chip: 
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)

But the patch appears to work.  

Is that to be expected?
Comment 64 stuart hayes 2007-08-01 11:55:10 UTC
The patch should work ok with any ECHI controller.

I'm a little surprised you saw this failure with the Intel EHCI controller, though, because I had tested my previous patch on Intel systems.  It's possible my previous testing was inadequate, though--I had been focusing on Broadcom systems--or that there's some other reason you were seeing the issue even though I didn't on Intel EHCI controllers.