This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Required update for better laptop support. Devel ACK.
Read ya, Phil
More comments. The patch pm-utils-0.99.3-hal.patch is wrong:
+ if [ "$FROMHAL" == "true" ]; then
+ pm-pmu --suspend || echo -n "mem" > /sys/power/state
+ dbus-send --session \
+ --dest=org.freedesktop.PowerManagement \
+ --type=method_call \
+ --print-reply /org/freedesktop/PowerManagement \
I think you've got the layers pretty badly mixed up here; there's no way at all
you can assume there's a session bus running let alone access it. One way around
this is to just use dbus-send to invoke Suspend() on HAL, see
which will then invoke pm-suspend _again_ but this time with the right quirks
pm-utils-0.99.3-autoquirk.patch: this is confusing; the whole point was that if
pm-suspend + friends _wasn't_ invoked from HAL we'd get the quirks from there
(if any). But this patch seems to suggest we're sometimes getting the quirks
from the old heuristic.
So in conclusion: pm-utils-0.99.3-hal.patch needs to be fixed to call a
well-known service and pm-utils-0.99.3-autoquirk.patch just needs to go I think.
Hope this helps.
Will upload a new EL5 SRPM for hal later today that passes the right quirks and
also invokes pm-suspend/pm-hibernate with the --from-hal option.
See bug 236907 comment 6 for details on updated hal packages. Thanks.
(In reply to comment #7)
> ...there's no way at all you can assume there's a session bus running let
> alone access it.
Totally agree. You can go session->system but not system->session.
> One way around
> this is to just use dbus-send to invoke Suspend() on HAL, see
I thought this was the plan all along.
> which will then invoke pm-suspend _again_ but this time with the right quirks
> (if any).
> also invokes pm-suspend/pm-hibernate with the --from-hal option.
Is this going upstream?
So do a:
dbus-send --system \
--print-reply /org/freedesktop/Hal/Device/SystemPowerManagement \
Talked with Richard, the final dbus-send call looks like this now:
dbus-send --system --print-reply \
We also discussed the autoquirk patch. The old autoquirks are disabled by
default and need to be manually activated with the --quirk-old quirk to be
inline with the other quirks (in case a customer has problems with the new HAL
Info based quirks and the old ones worked).
I've also fixed the Requires to >= hal-0.5.8.1.
Package is building atm and will be in the errata soon.
Read ya, Phil
(In reply to comment #11)
> dbus-send --system --print-reply \
> --dest=org.freedesktop.Hal \
> --type=method_call \
> /org/freedesktop/Hal/devices/computer \
> org.freedesktop.Hal.Device.SystemPowerManagement.Suspend \
IIRC pm-utils holds a lock here and there; make sure to give that lock up (since
HAL will invoke pm-utils; ie. there's some reentrancy issues here). Thanks.
Thanks for the catch, David. Fixed in latest build.
Read ya, Phil
From my testing on errata 2007:0632, I have found a problems with this fix. Hal
does not get called from pm-utils when run from the command line when you do not
specify any quirks.
On comment 15: this probably is the issue that Florian mentiones in
I cannot find pm-utils-0.99.3-6.el5.16. Brew indicates that it did not build.
Can you provide me with a link to the package?
It's there now.
Looks good to me. I looked over to the code and tested on a t60. I get the
same results with pm-suspend as using g-p-m to suspend. Quirks look the same
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.