Bug 208388 - HAL says powerbook cannot suspend; it can.
HAL says powerbook cannot suspend; it can.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks: FC6Target FC6Blocker
  Show dependency treegraph
 
Reported: 2006-09-28 06:41 EDT by David Woodhouse
Modified: 2013-03-05 22:47 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-05 14:14:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Tested patch. (4.54 KB, patch)
2006-09-28 17:29 EDT, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2006-09-28 06:41:45 EDT
gnome-power-manager knows how to suspend the PowerBook by using the PMU.
However, it fails to do so because it checks the
'power_management.can_suspend_to_ram' property, which is false.


Steps to Reproduce:
1.hal-get-property --udi /org/freedesktop/Hal/devices/computer --key
power_management.can_suspend_to_ram
  
Actual results:
false

Expected results:
true
Comment 1 David Zeuthen 2006-09-28 11:56:05 EDT
Hi,

There are some patches that should fix this at 

 http://lists.freedesktop.org/archives/hal/2006-September/006252.html

Any chance you can try to rebuild hal with these and let me know if they work?
They should apply to the SRPM.

An ugly workaround, in the interim, would be to use hal-set-property to set the
can_suspend_to_ram property... you need to be root to do this though.
Comment 2 David Woodhouse 2006-09-28 13:02:53 EDT
I'd already added a manual hal-set-property to /etc/rc.local, but you're right
-- it's ugly :)

HAL built with the above-referenced set of patches (all but the seemingly
unrelated smbios one) works fine, and both power_management.can_suspend_to_ram
and system.formfactor seem correct on my shinybook.

On Pegasos, however, I get this:
pegasos /home/dwmw2 $ hal-get-property --udi
/org/freedesktop/Hal/devices/computer --key power_management.can_suspend_to_ram
error: libhal_ctx_init: (null): (null)
hal_get_property.c 167 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was
not set.
pegasos /home/dwmw2 $ hal-get-property --udi
/org/freedesktop/Hal/devices/computer --key system.formfactor
error: libhal_ctx_init: (null): (null)
hal_get_property.c 167 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was
not set.
Comment 3 David Woodhouse 2006-09-28 14:46:44 EDT
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805392224 (LWP 2325)]
0x1001a274 in osspec_probe () at osspec.c:476
476             if (!strcmp(hal_device_property_get_string(d,
"power_management.type"), "pmu")) {
(gdb) bt
#0  0x1001a274 in osspec_probe () at osspec.c:476
#1  0x1000fd28 in main (argc=<value optimized out>, argv=<value optimized out>)
    at hald.c:579
#2  0x0fe5dd4c in generic_start_main () from /lib/libc.so.6
#3  0x0fe5df74 in __libc_start_main () from /lib/libc.so.6
#4  0x00000000 in ?? ()
Comment 4 David Woodhouse 2006-09-28 17:23:45 EDT
With this  incremental patch it seems to do the right thing on both PowerBook
and Pegasos. Will attach resulting (complete) patch.

--- hal-0.5.8.1/hald/linux/osspec.c~    2006-09-28 17:30:47.000000000 +0100
+++ hal-0.5.8.1/hald/linux/osspec.c     2006-09-28 22:20:15.000000000 +0100
@@ -448,6 +448,7 @@ set_suspend_hibernate_keys (HalDevice *d
        ssize_t read;
        size_t len;
        char *poweroptions;
+       char *pmtype;
        FILE *fp;

        can_suspend = FALSE;
@@ -473,8 +474,9 @@ set_suspend_hibernate_keys (HalDevice *d
                can_hibernate = TRUE;
        free (poweroptions);

-       if (!strcmp(hal_device_property_get_string(d, "power_management.type"),
"pmu")) {
-               /* We got our own helper for suspend PMU machines */
+       pmtype = hal_device_property_get_string(d, "power_management.type");
+       if (pmtype && !strcmp(pmtype, "pmu")) {
+               /* We have our own helper for suspend PMU machines */
                can_suspend = TRUE;
        }

@@ -530,6 +532,7 @@ detect_openfirmware_formfactor(HalDevice
                        { "AAPL"      , "desktop" },
                        { "iMac"      , "desktop" },
                        { "PowerMac"  , "desktop" },
+                       { "Pegasos"   , "desktop" },
                        {NULL, NULL }
                };
        const gchar *model =
Comment 5 David Woodhouse 2006-09-28 17:29:07 EDT
Created attachment 137347 [details]
Tested patch.
Comment 6 Matthias Clasen 2006-10-03 00:23:59 EDT
David (Z), any comment on this patch ?
Comment 7 David Zeuthen 2006-10-03 12:21:32 EDT
I committed something like the patch mentioned in comment 4 to git

http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=7c240196eae1cce8bf511dffaa7019e08383d1fb;hp=5cbbf1ca4fa93483373186c7a33eff02761137d8

At

 http://people.freedesktop.org/~david/hal-0.5.8.1-2.davidz1.src.rpm

there's a SRPM with all the patches from the hal 0.5.8 git branch (makes it grab
the patches from git so as to stay close to the branch); 

dwmw2, any chance you can test this SRPM? There's also another small fix for
SELinux and eject.
Comment 8 David Woodhouse 2006-10-03 17:22:13 EDT
Works on shinybook (can_suspend=true, laptop), and on Pegasos (false, desktop).

Reports (true, desktop) on Mac G5, which should probably be (false, desktop) --
we should probably report can_suspend=false for all the desktop machines, since
I don't think we can on most of them. But that isn't the end of the world.
Comment 9 David Woodhouse 2006-10-05 03:28:08 EDT
Just to confirm -- the package above is fine for FC6 final; the
'can_suspend=true' on G5 isn't a showstopper.
Comment 10 David Zeuthen 2006-10-05 14:14:03 EDT
Thanks for testing this David W. I'm closing this bug as a hal package with this
fix has just hit rawhide.

Btw, I think it's fine with can_suspend=TRUE for G5 too. The semantics behind
that property is more where the kernel is able to attempt to suspend (e.g. user
space can ask the kernel to try), not really whether it works for some version
and set of drivers. Btw, we're also going to add a bunch of quirk files for FC7
that tells how to suspend different boxen including what nasty video tricks we
need to do.

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