Most recent kernel where this bug did not occur: Distribution: Gentoo Hardware Environment: Motherboard: Chaintech 7VIL4, lspci joined Software Environment: "Vanilla" kernel, but compiled with genkernel Problem Description: 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 driver. 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 /proc/bus/usb/devices 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: /proc/bus/usb/devices /proc/bus/usb/004/001 /dev/bus/usb/004/001 And don't freeze with: /proc/bus/usr/00{1,2,3}/* /dev/bus/usr/00{1,2,3}/* 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] /var/log/debug
Created attachment 8677 [details] /var/log/dmesg
Created attachment 8678 [details] /var/log/kern.log
Created attachment 8679 [details] /var/log/messages
Created attachment 8680 [details] /var/log/syslog
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 usb_device_read(). As that's the only process in D state I'd assume that someone forgot to release that lock. 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. Thanks.
You should apply either this patch for 2.6.18 (it will appear in 2.6.18-rc4): http://marc.theaimsgroup.com/?l=linux-usb-devel&m=115435540308759&w=2 or this patch for 2.6.17 (submitted for the 2.6.17.x stable series): http://bugzilla.kernel.org/attachment.cgi?id=8591&action=view 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 the problem... 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 IC... 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...