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.

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.

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 ?? ()

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 =

Created attachment 137347 [details]
Tested patch.

David (Z), any comment on this patch ?

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.

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.

Just to confirm -- the package above is fine for FC6 final; the
'can_suspend=true' on G5 isn't a showstopper.

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.