Bug 6950

Summary: uhci-hcd freeze
Product: Drivers Reporter: Simon Lipp (simon.lipp)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: RESOLVED CODE_FIX    
Severity: normal CC: akpm, dbrownell, stern
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.17, 2.6.18-rc3 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 5089    
Attachments: /var/log/debug
/var/log/dmesg
/var/log/kern.log
/var/log/messages
/var/log/syslog
lspci -vvv output
2.6.18-rc3 kernel configuration
Set revision range for UCR-61S2B unusual_devs entry

Description Simon Lipp 2006-08-02 13:42:13 UTC
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 ;)
Comment 1 Simon Lipp 2006-08-02 13:43:58 UTC
Created attachment 8676 [details]
/var/log/debug
Comment 2 Simon Lipp 2006-08-02 13:44:44 UTC
Created attachment 8677 [details]
/var/log/dmesg
Comment 3 Simon Lipp 2006-08-02 13:45:38 UTC
Created attachment 8678 [details]
/var/log/kern.log
Comment 4 Simon Lipp 2006-08-02 13:46:35 UTC
Created attachment 8679 [details]
/var/log/messages
Comment 5 Simon Lipp 2006-08-02 13:47:49 UTC
Created attachment 8680 [details]
/var/log/syslog
Comment 6 Simon Lipp 2006-08-02 13:48:30 UTC
Created attachment 8681 [details]
lspci -vvv output
Comment 7 Simon Lipp 2006-08-02 13:50:01 UTC
Created attachment 8682 [details]
2.6.18-rc3 kernel configuration
Comment 8 Andrew Morton 2006-08-07 00:31:13 UTC
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.
Comment 9 Alan Stern 2006-08-07 08:53:38 UTC
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.
Comment 10 Simon Lipp 2006-08-08 04:49:47 UTC
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 ;)
Comment 11 Alan Stern 2006-08-08 11:36:23 UTC
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?
Comment 12 Simon Lipp 2006-08-09 05:49:10 UTC
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... 
Comment 13 Alan Stern 2006-08-09 07:49:59 UTC
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.
Comment 14 Simon Lipp 2006-08-14 01:35:08 UTC
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...
Comment 15 Alan Stern 2006-08-14 07:22:57 UTC
I'll submit the patch for inclusion in the standard kernel, and you can close
out the patch.
Comment 16 Greg Kroah-Hartman 2006-08-30 01:11:25 UTC
Thanks Alan for your work on this.  Am closing out...