Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158399 - hal fails to detect USB flash key sometimes
Summary: hal fails to detect USB flash key sometimes
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-21 17:36 UTC by Pete Zaitcev
Modified: 2015-01-04 22:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-05-04 13:45:49 UTC

Attachments (Terms of Use)
hald verbose, failed (deleted)
2005-05-21 17:59 UTC, Pete Zaitcev
no flags Details
hald verbose, succeded (deleted)
2005-05-21 18:01 UTC, Pete Zaitcev
no flags Details

Description Pete Zaitcev 2005-05-21 17:36:10 UTC
When inserting a USB flash key, sometimes hal does not create fstab entry.

This is load dependent. It only happens on older of my laptops. To reproduce,
I have to run Mozilla and do something to make a load; simultaneously insert
the key.

hald --verbose==yes yields wildly varying failure scenarios.
Sometimes it says "Ignoring hotplug event: no parent".
Sometimes everything seems good but hald does not
 match 20-storage-add-selinux.fdi and 90-fstab-sync.fdi
Sometimes it works

/var/log/messages shows usb-storage complaining READ CAPACITY failing
with key/ASC/ASCQ == 6/28/0, which should be retried by SCSI stack.

This bug may be a dup (same root cause) of bug 157703, but for two things:
 * 157703 deals with RHEL, so we need an extra bug to track,
 * 157703 has different hald --verbose=yes output.

Comment 1 Pete Zaitcev 2005-05-21 17:38:37 UTC
Adding David Zeuten to cc: as our HAL man.

Comment 2 Pete Zaitcev 2005-05-21 17:41:27 UTC
Basic experiments were done with:
Linux version 2.6.12-rc4-nip (zaitcev@niphredil) (gcc version 4.0.0 20050512
(Red Hat 4.0.0-5)) #3 SMP Sat May 21 09:04:42 PDT 2005

Comment 3 Pete Zaitcev 2005-05-21 17:59:03 UTC
Created attachment 114676 [details]
hald verbose, failed

This log has two types of failure (separate events)
 "Ignoring hotplug event - no parent" and
 not matching 90-fstab-sync.fdi

Comment 4 Pete Zaitcev 2005-05-21 18:01:30 UTC
Created attachment 114677 [details]
hald verbose, succeded

This log is from the same kernel, without reboot, only running without X
to prevent battstat applet and gamin from stealing CPU cycles.

Comment 5 Pete Zaitcev 2005-05-21 18:12:02 UTC
To be clear, Fedora kernel does exactly the same, only the poor 500MHz P6
is not fast enough to ever support hald --verbose=yes successfuly.
It only hotplugs correctly if hald is run with --daemon=yes
(and only sometimes).

[zaitcev@niphredil ~]$ cat /proc/version
Linux version 2.6.11-1.1323_FC4 ( (gcc version
4.0.0 20050518 (Red Hat 4.0.0-7)) #1 Thu May 19 03:20:21 EDT 2005
[zaitcev@niphredil ~]$ cat /proc/cmdline
ro root=/dev/hda1
[zaitcev@niphredil ~]$ rpm -q hal

Comment 6 David Zeuthen 2005-05-21 20:50:24 UTC
This looks rather strange - the output from comment 3 (with the failure) looks a
little bit like it's caused by the issue filed in bug 156167 as there are
hotplug events with sequence numbers 1070, 1072 and then 1071 processed in that
order. This looks wrong, are you using /sbin/udevsend as the hotplug
multiplexor? (/proc/sys/kernel/hotplug)

It's not exactly the same issue as in bug 156167 though but I think the root
cause is the same (timing, the sysfs event may fire too early) as hal is
complaining that there is no device symlink in /sys/block/sda/ and thus rejects
to probe for file systems etc.

Can you reproduce this with an earlier kernel than 2.6.12-rc3 or with the patch
from ?

Comment 7 David Zeuthen 2005-05-21 21:03:16 UTC
Btw, this is most likely different from bug 157703 as hal 0.5.x is very
different from hal 0.4.x (due to internal architectural changes) - the key
differences in 0.5.x are

 a) we punt the hotplug event reordering to udev (thus requiring /sbin/udevsend
instead of /sbin/hotplug as the hotplug multiplexor) since udev needs to do this
anyway. In 0.4.x hald reorders the hotplug events itself.

 b) much of the work is split into multiple hald processes so hald isn't put in
state D when bugs in e.g. usb-storage surfaces (in 0.5.x this is done by the
hald-addon-storage program) 

Comment 8 Pete Zaitcev 2005-05-22 06:04:51 UTC
/sbin/udevsend is used (it's a stock Rawhide userland for FC4T2+).

I tested the Kai's patch and it appears to fix the problem.

Comment 10 Pete Zaitcev 2005-05-22 22:06:23 UTC
Modified in 2.6.11-1.1340.

Kei's patch, just in case dies:

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -248,6 +248,7 @@ int device_add(struct device *dev)
 	if ((error = kobject_add(&dev->kobj)))
 		goto Error;
+	kobject_hotplug(&dev->kobj, KOBJ_ADD);
 	if ((error = device_pm_add(dev)))
 		goto PMError;
 	if ((error = bus_add_device(dev)))
@@ -260,14 +261,13 @@ int device_add(struct device *dev)
 	/* notify platform of device entry */
 	if (platform_notify)
-	kobject_hotplug(&dev->kobj, KOBJ_ADD);
 	return error;
+	kobject_hotplug(&dev->kobj, KOBJ_REMOVE);
 	if (parent)

Comment 11 Dave Jones 2005-06-27 23:11:54 UTC
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done


Comment 12 Dave Jones 2005-09-30 06:43:08 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel ( As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.


Comment 13 Dave Jones 2005-11-10 19:47:49 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

Comment 14 Dave Jones 2006-02-03 05:43:41 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Comment 15 John Thacker 2006-05-04 13:45:49 UTC
Closing per previous comment.

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