Re: [gpm] hal failed to suspend

["dennis wavomba" <dwavomba gmail com>]

Thanks for the response Richard,

The output of the first dbus-send is (suspend):

$ dbus-send --system --print-reply \
> --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer \
> org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
method return sender=:1.0 -> dest=:1.248
  uint32 1

The second response is (hibernate):
$ dbus-send --system --print-reply \
> --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer \
> org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate
method return sender=:1.0 -> dest=:1.260
  uint32 1

Please advise. Thanks

Dennis

On 2/1/07, Richard Hughes <hughsient gmail com> wrote:
> Sorry for the delay, been a busy week.
>
> On Wed, 2007-01-24 at 19:47 -0500, dennis wavomba wrote:
> > I'm acquainting myself with gnome-power-manager. The gconf keys for
> > suspend and hibernate are set to TRUE and all other functions of g-p-m
> > seem to work. However, whenever I click on hibernate (or suspend) from
> > the panel applet (or from gnome's shutdown menu), I get a hal error
> > popup that says "Hal failed to Hibernate/Suspend please see the FAQ".
> > Also, I'm running a kernel that supports suspend2 and can hibernate
> > using the command line via "sudo hibernate" which works fine. I'm on
> > archlinux and I suspect it could be my configuration. My hibernate
> > scripts are the standard ones and I can see that the hibernate script
> > is supported. Hal could be blocking g-p-m from executing suspend? How
> > can I rectify this. Sorry for the long post and thanks for any
> > assistance
>
> What effect does the following have:
>
> dbus-send --system --print-reply
> --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer
> org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
>
> dbus-send --system --print-reply
> --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer
> org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate
>
> If this works it's a g-p-m problem, if not then we should get some more
> debugging details.
>
> Richard.