Bug 312761

Created attachment 211441 [details]
pm-suspend log from "failed" hibernate

Created attachment 211451 [details]
portion of /var/log/messages related to "failed" hibernate

Afaik, the applet belongs to gnome-power-manager, the pm-suspend does not
contain any warnings, therefore I guess it is an applet issue.
Maybe you need to increase verbosity to get a helping log, because the critical
log entries seem to be:

Sep 29 18:02:37 valkyrie gnome-power-manager: (mjs) Resuming computer
Sep 29 18:02:37 valkyrie gnome-power-manager: (mjs) hibernate failed

But a reason why it failed is missing.

OK How do I get better debug logs?  Thanks.

David, any clue about this ?

g-p-m is expect the wrong return types from hal; so I wrote a patch (will attach
in the next comment) but for some reason beyond me I still get the "Sleep
problem" dialog from g-p-m. Richard, what gives?

FWIW, it works fine using dbus-send:

[davidz@oneill ~]$ dbus-send --print-reply --system --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.DBus.Introspectable.Introspect |grep -2 Suspend
  </interface>
  <interface name="org.freedesktop.Hal.Device.SystemPowerManagement">
    <method name="Suspend">
      <arg name="num_seconds_to_sleep" direction="in" type="i"/>
      <arg name="return_code" direction="out" type="i"/>
    </method>
    <method name="SuspendHybrid">
      <arg name="num_seconds_to_sleep" direction="in" type="i"/>
      <arg name="return_code" direction="out" type="i"/>
[davidz@oneill ~]$ 
[davidz@oneill ~]$ 
[davidz@oneill ~]$ dbus-send --print-reply --system --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
method return sender=:1.4 -> dest=:1.434 reply_serial=2
   int32 0
[davidz@oneill ~]$ 
[davidz@oneill ~]$ 
[davidz@oneill ~]$ dbus-send --print-reply --system --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.DBus.Introspectable.Introspect |grep -2 Hibernate
      <arg name="return_code" direction="out" type="i"/>
    </method>
    <method name="Hibernate">
      <arg name="return_code" direction="out" type="i"/>
    </method>
[davidz@oneill ~]$ dbus-send --print-reply --system --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate
[davidz@oneill ~]$ 
[davidz@oneill ~]$ 
[davidz@oneill ~]$ dbus-send --print-reply --system --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate
method return sender=:1.4 -> dest=:1.487 reply_serial=2
   int32 0

Created attachment 217621 [details]
Patch to fix expected return types

This patch should go upstream.

OK, so it turns out we're getting a D-Bus timeout. Actually g-p-m got codepaths
to handle this [1] but the call site passes NULL for the GError so we never get
to examine this and properly handle timeouts. This patch

http://cvs.fedoraproject.org/viewcvs/devel/gnome-power-manager/gnome-power-manager-2.20.0-use-gerror.patch?rev=1.1&view=auto

takes care of that. I've tested and it works. Also, there's an update of the
patch in comment 7; you want this one instead

http://cvs.fedoraproject.org/viewcvs/devel/gnome-power-manager/gnome-power-manager-2.20.0-expected-return-types.patch?rev=1.1&view=auto

So this is fixed in -3 which is building right now. You can beat the rush and
get the 0day warez right here

http://koji.fedoraproject.org/koji/taskinfo?taskID=184871

Thanks.

[1] : because dbus-glib sucks and don't let you specify INT_MAX or a magic
sentinel to say "unlimited" as a timeout; this is really needed because the
(wall-clock) time between when Hibernate() is invoked and when it returns (e.g.
when the system resumes) can be infinitely long.

OK Got it.  A quick hibernate-resume seems to work fine.

*** Bug 330191 has been marked as a duplicate of this bug. ***

quick hibername-resumes are the easy part, you need to leave it overnight for a
correct test.  

gnome-power-manager-2.20.0-6.fc8 still fails. 

I just hibernated and then set my clock forward two months (party like it's
December 29th! :-) and resumed and things are fine.  

Andrew -- If you're still seeing a failure message, it's likely due to something
actually failing.  Please open another report and include
/var/log/pm-suspend.log from when it says it fails.

(sorry for the late reply).  Confirming fixed, as I've not seen this in months.