Bug 6089 - processes can go in D-state when sg bad happened to USB pluged devices
Summary: processes can go in D-state when sg bad happened to USB pluged devices
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Greg Kroah-Hartman
Depends on:
Blocks: USB
  Show dependency tree
Reported: 2006-02-17 09:20 UTC by Thierry Vignaud
Modified: 2008-09-22 16:22 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.17
Tree: Mainline
Regression: ---

trace of a process accessing /proc/bus/usb/devices (542 bytes, text/plain)
2006-09-18 12:44 UTC, Thierry Vignaud

Description Thierry Vignaud 2006-02-17 09:20:26 UTC
Most recent kernel where this bug did not occur: 2.6.12  (but nothing related  
has changed in the usb subsystem since)  
Distribution: Mandriva  
Problem Description: 
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
Comment 1 Martin J. Bligh 2006-02-17 09:27:26 UTC
Output of ALT+sysrq+t would probably be useful
Comment 2 Greg Kroah-Hartman 2006-02-17 11:21:42 UTC
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?
Comment 3 Greg Kroah-Hartman 2006-03-06 10:33:56 UTC
Closing due to lack of response.

If this is still a problem, please reopen
with the requested information.

Comment 4 Thierry Vignaud 2006-07-27 11:07:37 UTC
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.
Comment 5 Thierry Vignaud 2006-07-27 11:12:42 UTC
s/until./until xawtv is closed./
Comment 6 Greg Kroah-Hartman 2006-07-27 16:09:37 UTC
Can you test 2.6.17?  It's been out for a while now :)
Comment 7 Thierry Vignaud 2006-08-03 04:37:56 UTC
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.
Comment 8 Greg Kroah-Hartman 2006-08-30 01:17:42 UTC
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
Comment 9 Thierry Vignaud 2006-09-18 12:44:34 UTC
Created attachment 9047 [details]
trace of a process accessing /proc/bus/usb/devices
Comment 10 Thierry Vignaud 2006-10-03 07:58:05 UTC
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.
Comment 11 Luc Saillard 2006-10-03 08:44:43 UTC
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.
Comment 12 Natalie Protasevich 2007-08-11 14:46:12 UTC
Have you had chance to test with recent kernels? Many problems with disconnect and unregister were fixed since then.
Comment 13 Thierry Vignaud 2007-08-13 03:32:47 UTC
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))

Note You need to log in before you can comment on or make changes to this bug.