Most recent kernel where this bug did not occur:
Hardware Environment: Motherboard: Chaintech 7VIL4, lspci joined
Software Environment: "Vanilla" kernel, but compiled with genkernel
The program that read /proc/bus/usb/devices go in D state and is unkillable.
This problem doesn't appears if the kernel is compiled without UHCI support -
and all the EHCI stuff work fine - so I think this problem comes from the UHCI
It looks like bug#6089, but I don't need to plug nor unplug a device to have it.
I tried booting with noacpi and noapic, but it didn't change anything, so it's
probably not a come back of bug#10 ;)
Unkillable process'PID is 5663 (ps aux | grep cat gives:)
root 5663 0.0 0.1 2656 580 tty1 D+ 14:44 0:00 cat
I made a sysrq-T, which is in the joined dmesg (and kern.log)
The problem also exists for the files in /dev/bus/usb, making libusb (and
hotplug) not happy :)
Precisely, cat freeze with:
And don't freeze with:
Steps to reproduce:
cat /proc/bus/usb/devices. But I think this don't cause any problem on your
linux box ;)
Created attachment 8676 [details]
Created attachment 8677 [details]
Created attachment 8678 [details]
Created attachment 8679 [details]
Created attachment 8680 [details]
Created attachment 8681 [details]
lspci -vvv output
Created attachment 8682 [details]
2.6.18-rc3 kernel configuration
Looks like we deadlocked on usb_lock_device(bus->root_hub) in
As that's the only process in D state I'd assume that someone forgot to release
I cannot see where, but the usb_lock_device() handling is rather opaque.
Are you able to identify a kernel version where this first started happening?
And it might help if you can tell us which drivers are in use.
You should apply either this patch for 2.6.18 (it will appear in 2.6.18-rc4):
or this patch for 2.6.17 (submitted for the 2.6.17.x stable series):
There's a good chance either one of those will fix the problem.
I did have the problem under 2.6.5. No problem in the 2.4.x kernels (with x <=
21). I'll try 2.4.32 tomorrow, or today PM if I can find it on a CD (I have a
slow internet connexion ;)) - i tried to compile 2.6.0 yesterday, but it seem to
don't compile with recent GCC (I tried with 3.4.4 and 4.1.1)
I use 2 usb drivers (except usbcore, ehci-hcd and uhci-hcd ;)): usbhid (for an
usb mouse) and usb-storage. If I unplug my mouse and then reboot, there's still
Patches didn't fix anything (tried the 2.6.17 patch, the 2.6.18-rc3 patch and
the 2.6.18-rc4 kernel)
Thanks for your replies ;)
Created attachment 8732 [details]
Set revision range for UCR-61S2B unusual_devs entry
I think this patch will work around your problem. Apparently it has nothing to
do with uhci-hcd; it's an error in usb-storage. Is your USB storage device by
any chance a card reader?
It works !!!! Big big thanks :)
Yes, I have a card reader (I never used it ;)), but I don't think it's an USB
one since it's an internal card reader...
It's possible for USB devices to be internal. But I guess it's not so easy for
you to tell whether this is the device that shows up in the kernel log as a
Generic USB Storage Device. You'd probably have to open up the case and look at
the connecting cables, maybe even try disconnecting them.
By the way, that patch disables code in the usb-storage driver that's intended
to activate all four slots in the card reader. Apparently it doesn't work with
your reader, and it hangs instead.
Ok, my card reader is an USB one. And it seem to be the device which cause the
problem (it's the the USB-storage device which appear on the logs): if I unplug
it, everything is OK (with a non-patched kernel ;)).
I tried to find the vendor and the model of this device, but it's not written on
(also out of the case). lsusb don't tell anything (just idVendor=0x1019 and
idProduct=0x0c55, if it can help you ;)), and lshal just say that the vendor is
Anyway, it's not critical if you can't make the 4 slots working, since I don't
use the card reader ;). If you think it's better (not enough informations, and I
have no way to test my card reader: I have no card at all ;)), you can close the
bug, and I'll open a new one when (and if) I have to use it someday, hoping I'd
have more informations...
I'll submit the patch for inclusion in the standard kernel, and you can close
out the patch.
Thanks Alan for your work on this. Am closing out...