Bug 15113 - hald doesn't react properly to repeated calls to hal-disable-polling
Summary: hald doesn't react properly to repeated calls to hal-disable-polling
Status: NEW
Alias: None
Product: hal
Classification: Unclassified
Component: hald (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-18 15:51 UTC by Ignacy Gawedzki
Modified: 2008-03-18 15:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
hald verbose output (434.08 KB, text/plain)
2008-03-18 15:51 UTC, Ignacy Gawedzki
Details

Description Ignacy Gawedzki 2008-03-18 15:51:47 UTC
Created attachment 15265 [details]
hald verbose output

If hal-disable-polling is run twice with no sleep in between, for two different devices, then the second device doesn't get its storage.media_check_enabled property updated as it ought to.  I suspect some kind of a race condition there, between the moment hald reloads files from /etc/hal/fdi/information and a new file is added there.  Apparently calls to libhal_device_reprobe() don't help, hald doesn't seem to notice that there is a new file in this directory.

I initially wanted to write a script that puts my multicard USB reader to sleep by echoing the appropriate string to /sys/.../power/level, but polling addons have to be disabled first for all of the four luns.  Too bad there is no way, AFAIK, to tell hald to kill the addons until further notice.

Attached is the log from hald --verbose=yes --daemon=no for an experiment in which the hal-disable-polling worked as expected (somehow) but hal-disable-polling --enable-polling failed.
Comment 1 Ignacy Gawedzki 2008-03-18 15:55:51 UTC
I forgot to specify: kernel 2.6.24, x86_64, hald from git, udev 113, Ubuntu Gutsy. 


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.