Bug 138259 - HAL hangs upon connecting usb flash drive
Summary: HAL hangs upon connecting usb flash drive
Keywords:
Status: CLOSED DUPLICATE of bug 136255
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-06 12:51 UTC by Mikko Huhtala
Modified: 2013-03-06 03:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:06:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mikko Huhtala 2004-11-06 12:51:43 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
Hal hangs on my system when a usb flash drive is connected. Connecting
the flash drive did work correctly twice using this kernel/udev/hal
combination, but even then unmounting /media/usbdisk caused hal to
hang and the drive could not be re-connected. Now hal seems to hang
systematically every time the drive is connected, even immediately
after boot. The messages in the system log complain about missing
configuration for this device, but as I mentioned, it did work a
couple of times, so it appears missing configuration is not the real
problem.

The system is an up-to-date FC3 release candidate, at least as far as
I can tell. The release candidate repositiories seemed to appear at
random addresses and now they have disappeared, so there is no way of
telling (the advantage of the rc excercise over releasing and
mirroring packages in the 'development' stream remains a mystery to
me). The versions are:

hal-0.4.0-10
kernel-2.6.9-1.667
udev-039-6.FC3.1
dbus-0.22-10

The hwconf entry for the USB hub is as follows:

class: USB
bus: PCI
detached: 0
driver: uhci-hcd
desc: "Intel Corp. 82801BA/BAM USB (Hub #1)"
vendorId: 8086
deviceId: 2442
subVendorId: 147b
subDeviceId: 0507
pciType: 1
pcidom:    0
pcibus:  0
pcidev: 1f
pcifn:  2




Version-Release number of selected component (if applicable):
hal-0.4.0-10

How reproducible:
Always

Steps to Reproduce:
1. Boot FC3
2. Connect USB flash drive
3. Do lshal or try to kill hald
    

Actual Results:  The usb drive does not get a mount point and is not
mounted. Hald apparently hangs; the process cannot be killed and does
not respond to signals. Lshal returns the following error:

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



Expected Results:  Usb drive gets mounted on /media/usbdisk and hald
keeps working.

Additional info:

The following appears in /var/log/messages upon connecting the usb
flash drive:

Nov  6 14:31:01 urquell kernel: usb 1-1: new full speed USB device
using address 3
Nov  6 14:31:02 urquell kernel: Initializing USB Mass Storage driver...
Nov  6 14:31:02 urquell kernel: scsi1 : SCSI emulation for USB Mass
Storage devices
Nov  6 14:31:02 urquell kernel:   Vendor: Generic   Model: USB Flash
Disk    Rev: 2.00
Nov  6 14:31:02 urquell kernel:   Type:   Direct-Access              
       ANSI SCSI revision: 02
Nov  6 14:31:02 urquell kernel: sda: Unit Not Ready, sense:
Nov  6 14:31:02 urquell kernel: Current : sense key Unit Attention
Nov  6 14:31:02 urquell kernel: Additional sense: Not ready to ready
change, medium may have changed
Nov  6 14:31:02 urquell kernel: sda : READ CAPACITY failed.
Nov  6 14:31:02 urquell kernel: sda : status=1, message=00, host=0,
driver=08
Nov  6 14:31:02 urquell kernel: Current sd: sense key Unit Attention
Nov  6 14:31:02 urquell kernel: Additional sense: Not ready to ready
change, medium may have changed
Nov  6 14:31:02 urquell kernel: sda: Write Protect is off
Nov  6 14:31:02 urquell kernel: sda: assuming drive cache: write through
Nov  6 14:31:07 urquell wait_for_sysfs[3682]: either wait_for_sysfs
(udev 039) needs an update to handle the device
'/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0/host1/1:0:0:0'
properly (no bus device link) or the sysfs-support of your device's
driver needs to be fixed, please report to
<linux-hotplug-devel.net>
Nov  6 14:31:07 urquell wait_for_sysfs[3692]: either wait_for_sysfs
(udev 039) needs an update to handle the device '/block/sda' properly
(no bus device link) or the sysfs-support of your device's driver
needs to be fixed, please report to
<linux-hotplug-devel.net>
Nov  6 14:31:17 urquell hal.hotplug[3694]: timout(10000 ms) waiting
for /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0/host1/1:0:0:0
Nov  6 14:31:27 urquell scsi.agent[3711]: Attribute
/sys/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0/host1/1:0:0:0/type
does not exist

Comment 1 David Zeuthen 2004-11-08 19:10:34 UTC
Hi - what is the output of 'ps aux|grep hald'?

Thanks,
David

Comment 2 David Zeuthen 2004-11-08 19:12:00 UTC
Btw, to clarify what I've asked for in comment 1, I'll need the output
from 'ps aux|grep hald' when the hal daemon is hanging.

Comment 3 Mikko Huhtala 2004-11-08 21:25:46 UTC
I cannot boot my machine right now, so this 'ps' is at a time of a
couple of days after trying to kill hald.

mhuhtala urquell:~ > ps aux | grep hald
root      2617  0.0  0.8  6380 4360 ?        Ds   Nov06   0:00 hald

I'm downloading the FC3 final now and I'll try again with a clean
install. The test system was updated with yum from FC2 to FC3
development stream to FC3 release candidates, so all kinds of strange
things may have happened.

Mikko


Comment 4 Mikko Huhtala 2004-11-09 00:34:43 UTC
I tested this on a fresh install of FC3 final + updates. The versions are

kernel-2.6.9-1.667
udev-039-10.FC3.1
hal-0.4.0-10
dbus-0.22-10

The usb flash drive worked correctly once. Icon appeared on GNOME
desktop, access worked ok, 'Unmount volume' from GNOME menu worked
without complaints. When the drive then disconnected and re-connected,
the it does not get mounted and hal hangs. The process status is as
follows:

mhuhtala urquell:~ > ps aux | grep hal
root      2780  0.0  0.9  7260 4752 ?        Ds   02:10   0:01 hald

Mikko


Comment 5 David Zeuthen 2004-11-09 14:47:35 UTC
Right - the hald process is stuck in uninteruptable sleep (state D),
most probably because of a bug in the usb-storage driver. This issue
can easily be reproduced with a more aggresive test program; it is
being tracked in bug 136255 - see that bug for details. Closing this
bug as a duplicate.

*** This bug has been marked as a duplicate of 136255 ***

Comment 6 Red Hat Bugzilla 2006-02-21 19:06:48 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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