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 140964
Summary: | Detection of USB disk drives does not always function | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Terry Linhardt <linhardt> |
Component: | gnome-volume-manager | Assignee: | John (J5) Palmieri <johnp> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | jkeck, sbergman |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-21 19:07:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Terry Linhardt
2004-11-27 00:30:22 UTC
I can confirm that on my fully updated FC3 box, if I insert and remove the compact flash from my usb reader several times, the icon will eventually refuse to appear and a reboot is required to get it "working" again. If I watch /var/log/messages, I see kernel: messages indicating that the device is being recognized. # service restart haldaemon # service restart messagebus has no effect. This sounds like a gnome-volume-manager issue to me. Nautilus only shows the icon if the volume was mounted. This sounds like a kernel issue with the usbstorage drivers. A couple of questions: * Can you do an 'lshal' after this happens or does it just hang? * Does the fstab (and /media) entry show up for the device and just not show up in Nautilus? * Can you mount the device manualy? After a reboot (when things work properly), an "lshal" yield about 1258 lines of output. (lshal | wc -l). It took about 5 tries (unmount, remove device, re-insert in USB port) before I again had the problem. At that point, the lshal command gave this output: lshal version 0.4.0 libhal.c 767 : org.freedesktop.DBus.Error.NoReply raised "Message did not receive a reply" *** [DIE] lshal.c:dump_devices():71 : Couldn't obtain list of devices After the "failure", *only* my cd drive shows up under /media. (Which is NOT a usb device). The usb "pen drive" no longer shows up under /media. And NO, I cannot mount the device manually. As a follow-up to Comment #4, let me note that when the device is in the USB drive, it is mounted on /dev/sda1. However, after I experience a failure, if I *try* to mount the device manually: "mount /dev/sda1 /media/usbdrive" I receive an error message stating that "/dev/sda1" does not exist. Sounds like a dup of 136255. There is a timing issue with pulling out the device when HAL is doing an open() which causes the open to not return. Since the open call is in the kernel you get a deadlock that HAL can not exit out of (kernel will not let processes exit on IO) which then requires the reboot to get things working again. This needs to be fixed in the kernel. *** This bug has been marked as a duplicate of 136255 *** Assuming this is a kernel fix, any time estimate as to when we would get a fix. Also, what would be considered a work-around in the mean time?? Thanks I assume the new ub drivers which don't use scsi emulation will fix this though they currently crash for other reasons. It is hard to say when this will be fixed by the kernel guys. Best bet is to ask the maintainer of usb-storage and to test out the ub drivers and filing bugs on it upstream. Workaround is to try and not to unmount too often. I know that sucks. Also this bug only happens on certant hardware setups or I would be getting a lot more bugs filed against this so you might want to see if you can reproduce this on other computers or setups (for instance hubs or certant USB controlers might cause the timing issue). Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |