Kernel Bug Tracker – Bug 6089
processes can go in D-state when sg bad happened to USB pluged devices
Last modified: 2008-09-22 16:22:31 UTC
Most recent kernel where this bug did not occur: 2.6.12 (but nothing related
has changed in the usb subsystem since)
the kernel offer a view of USB devices
through /proc/bus/usb/devices. however, the program that read that file can go
in D state, thus becoming unkillable, if sg bad happens (eg a device that is
currently used by a process is unplugged).
it's not expected for programs to get freezed and unkillable while reading
such /proc files.
the kernel should maintain a view of the usb tree so that other processes won't
becoming iresponsible. this view should be atomically updated when devices are
Steps to reproduce:
- plug an USB webcam,
- run xawtv in order to grab video,
- unplug the webcam
Output of ALT+sysrq+t would probably be useful
Yes, things have changed in the kernel since then. We should not be accessing
the usb bus anymore when you cat that file (and it's a usbfs file, not a proc
file, usbfs just is mounted in a directory in proc.)
Can you retest with 2.6.15 and let us know if it's still a problem or not?
Closing due to lack of response.
If this is still a problem, please reopen
with the requested information.
This bug is still true as of 2.6.16. Once a webcam is unpluged (here a pwc
driven one) whereas it's still used by xawtv, then all programs that
read /proc/bus/usb/devices got stuck on read() and go in D state until xawtv.
s/until./until xawtv is closed./
Can you test 2.6.17? It's been out for a while now :)
Still valid. any process opening /proc/bus/usb/devices is blocked in D state
until the process that was using the unplugged USB device exits.
Can you do a SysRq-T when the processes are stuck so that we can see
where in the kernel they are hanging? Please attach the output, don't put it
Created attachment 9047 [details]
trace of a process accessing /proc/bus/usb/devices
There're two bugs here:
- pwc driver should cleanly handle unplug of device
whether it's in use or not (and return the appropriate
error code to the processes using it)
- the usb layer should be made more robust against such bugs
(because obviously one cannot ensure all usb drivers behave
smoothly on device unplug) maybe by maintaining its own list
of devices w/o querying the drivers (me not begin a kernel developer,
my explanation may be wrong
The unplug has be more tough. The driver has to accept
that the box can be unplugged at any time.
Did you test with the pwc driver 10.0.x or the one in the kernel (9.xxx) ?
Kernel 2.6.18 has a new pwc driver with some logic change when unplugging the
webcam. I've not test this kernel, but i use 2.6.17+pwc-10.0.12 that can be
found on my website without problem.
Have you had chance to test with recent kernels? Many problems with disconnect and unregister were fixed since then.
I can restest but honestly I fear nothing was changed. I'ven't seen any commit for uncoupling /proc entries (whereas there're some patches for decoupling sysfs which triggered similar bugs (or it looks like))