Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 136255 - USB devices hang programs if pulled out on an open()
Summary: USB devices hang programs if pulled out on an open()
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
URL:
Whiteboard:
: 138259 140964 143785 152308 (view as bug list)
Depends On:
Blocks: FCMETA_USB
TreeView+ depends on / blocked
 
Reported: 2004-10-18 22:01 UTC by John (J5) Palmieri
Modified: 2013-03-13 04:46 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-15 18:03:10 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
Test program (deleted)
2004-10-18 22:03 UTC, John (J5) Palmieri 		no flags Details
Kernel backtrace (deleted)
2004-10-19 15:37 UTC, John (J5) Palmieri 		no flags Details
Oops in SCSI subsystem (deleted)
2004-12-05 21:38 UTC, Didier 		no flags Details
USB detach/reattach syslog (deleted)
2004-12-19 13:13 UTC, Didier 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 3595 0 None None None Never

Description John (J5) Palmieri 2004-10-18 22:01:35 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041012 Epiphany/1.4.4

Description of problem:
Programs that attempt to open a usb-storage device while it is being
pulled out will hang in the open call even if O_NONBLOCK is set.  This
is serious because HAL polls devices such as cdroms and floppies to
know when media has been inserted.  Pulling out the device when a poll
happens causes HAL to hang and devices are no longer autodetected and
configured.

Version-Release number of selected component (if applicable):
tried on kernel-2.6.8 releases 1.541, 1.610, 1.627

How reproducible:
Always

Steps to Reproduce:
1. Plug in a USB mass storage device
2. Note the device node it attaches to
3. Edit the enclosed test program to open this device node
4. gcc test.c -o test
5. strace -tt ./test
6. Yank the usb device out
    

Actual Results:  Program freezes and you can't kill it.

Expected Results:  program continues working

Additional info:
Comment 1 John (J5) Palmieri 2004-10-18 22:03:15 UTC 
Created attachment 105403 [details]
Test program
Comment 2 John (J5) Palmieri 2004-10-19 15:37:10 UTC 
Created attachment 105450 [details]
Kernel backtrace

Backtrace of test program after it hangs.
Comment 3 David Zeuthen 2004-11-09 14:47:38 UTC 
*** Bug 138259 has been marked as a duplicate of this bug. ***
Comment 4 Chris Wilcox 2004-11-10 19:54:07 UTC 
Have an identical problem using RedHat Fedora Core 2, with a 2.6.9 
kernel.  My program polls for USB device insertion and removal by 
opening /dev/sda, /dev/sdb, etc.  I tried with and without O_NONBLOCK,
and it hangs intermittently (but often) either way on device 
removal.  Is there a better way to detect insertion and removal 
events without polling?
Comment 5 Rob Kirkbride 2004-11-22 14:36:45 UTC 
I actually think the problem is worse than this. If the device is
unmounted rather than being ejected it produces a hang in the hal
daemon (presumably the same hang as above). This was a suggestion by
Kay Siever on the hot plug mailling list and appears to work. ie. This
isn't just about pulling the key out out.
The problem is if you forget to do the eject rather than the unmount,
your USB bus effectively locks up requiring a reboot.
Comment 6 Mikko Huhtala 2004-11-22 16:55:51 UTC 
> I actually think the problem is worse than this. [...]

Yes, that is also what I reported in my original bug. That bug
(138259) got resolved as a duplicate of this one.

Mikko
Comment 7 Mark Levitt 2004-11-23 16:04:12 UTC 
I have seen the same thing. 
1)Plug in a USB key drive. Drive is mounted and shows up on desktop.
2)Right click and click Unmount volume. Driver icon goes away.
3) Remove drive.
4) Plug drive in again. Drive is mounted and shows up on desktop.
5) Right click and click Unmount volume. Error message that the device
is busy.
6) Remove device. Icon goes away. 
7) Plug drive in a third time, nothing happens.
Comment 8 Mark Levitt 2004-11-23 16:05:47 UTC 
Sorry, I should have mentioned that this is on Fedora Core 3 kernel v.
 2.6.9-1.681_FC3
Comment 9 John (J5) Palmieri 2004-11-23 16:46:27 UTC 
Mark Levitt, I think that is a different bug alltogether.  It looks
more like bug #132572.  Certant USB devices break the massstorage drivers.
Comment 10 John (J5) Palmieri 2004-11-30 16:20:12 UTC 
*** Bug 140964 has been marked as a duplicate of this bug. ***
Comment 11 David Zeuthen 2004-12-02 15:33:21 UTC 
*** Bug 138906 has been marked as a duplicate of this bug. ***
Comment 12 Didier 2004-12-02 16:49:46 UTC 
Any relation to bug #140356 (SCSI subsystem lockup when removing
IEEE1394 devices) ?
Comment 13 Rob Kirkbride 2004-12-03 12:45:44 UTC 
I have tried Kernel 2.6.9-RC2 and it works fine with FC3. It mounts
devices etc. as it should and the hal daemon appears to does its job
correctly. I've been running it for a few so far and it's been fine.

Hopefully an offical kernel update can be issued with at least the USB
corrections from RC2 in.
Comment 14 Steve Bergman 2004-12-04 17:23:02 UTC 
My kernel is 2.6.9-1.681_FC3 and the problem persists.  I just
rebooted and unplugged, plugged my 64MB CF card into my Dazzle* 8-in-1
High Speed USB 2.0 reader and it recognized it when I first started
gnome, and it found it again when I unplugged, plugged, but then when
I tried it again it fails to recognize it.  Logging out and logging
back in does not help.  Nor does restarting haldaemon.  Only a reboot
gets it "working" again.  Though only for a very short time until it
fails again.
Comment 15 John (J5) Palmieri 2004-12-05 10:59:37 UTC 
Card readers are polled by HAL to detect media insertion.  This
involves an open() so if you pull the card out while the reader is
being polled the system call hangs.
Comment 16 Didier 2004-12-05 21:38:19 UTC 
Created attachment 107913 [details]
Oops in SCSI subsystem

As a follow-up to my own comment #12, "cat /proc/scsi/sci" hangs too after some
detach/attach cycles, same behaviour as bug #140356 (where SCSI hangs after one
detach, reproducable).

Contrary to bug #140356, I do get an oops here (see attachment).
Comment 17 Didier 2004-12-19 13:08:21 UTC 
Problem persists with 2.6.9-1.715_FC3 : detaching and reattaching a
digicam (Pentax Optio 750Z) to the USB port hangs the SCSI subsystem,
requiring a reboot to restore USB and/or Firewire operations (my FC2
uptimes of 20+ days are decimated).

root        29  0.0  0.0     0    0 ?        D    12:49   0:00 [khubd]
root      3940  0.0  0.9  8916 7196 ?        Ds   12:51   0:02 hald
didier    7822  0.2  1.6 24556 12516 ?       D    13:31   0:04
/usr/bin/gtkam
didier    8031  0.2  3.9 125004 30600 ?      Dl   13:32   0:03 gthumb
root      8658  0.0  0.0     0    0 ?        D    13:37   0:00 [scsi_eh_1]
root      8659  0.0  0.0     0    0 ?        S    13:37   0:00
[usb-storage]
root      8993  0.0  0.0  3812  636 pts/6    D+   13:38   0:00 fdisk -l
Comment 18 Didier 2004-12-19 13:13:01 UTC 
Created attachment 108855 [details]
USB detach/reattach syslog

After syncing and detaching, udev removes SCSI node, and kernel reports scsi &
FAT I/O errors.
After reattaching, udev recreates sda node, but hal times out.
Comment 19 David Zeuthen 2005-01-03 19:07:12 UTC 
*** Bug 143785 has been marked as a duplicate of this bug. ***
Comment 20 David Zeuthen 2005-03-28 18:40:25 UTC 
*** Bug 152308 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.