Red Hat Bugzilla – Bug 136255
USB devices hang programs if pulled out on an open()
Last modified: 2013-03-13 00:46:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
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
Version-Release number of selected component (if applicable):
tried on kernel-2.6.8 releases 1.541, 1.610, 1.627
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
Created attachment 105403 [details]
Created attachment 105450 [details]
Backtrace of test program after it hangs.
*** Bug 138259 has been marked as a duplicate of this bug. ***
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?
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.
> 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.
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
6) Remove device. Icon goes away.
7) Plug drive in a third time, nothing happens.
Sorry, I should have mentioned that this is on Fedora Core 3 kernel v.
Mark Levitt, I think that is a different bug alltogether. It looks
more like bug #132572. Certant USB devices break the massstorage drivers.
*** Bug 140964 has been marked as a duplicate of this bug. ***
*** Bug 138906 has been marked as a duplicate of this bug. ***
Any relation to bug #140356 (SCSI subsystem lockup when removing
IEEE1394 devices) ?
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.
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
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.
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
Contrary to bug #140356, I do get an oops here (see attachment).
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
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
root 8993 0.0 0.0 3812 636 pts/6 D+ 13:38 0:00 fdisk -l
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.
*** Bug 143785 has been marked as a duplicate of this bug. ***
*** Bug 152308 has been marked as a duplicate of this bug. ***