GNOME Bugzilla – Bug 332888
Get "Suspend Failed" notification bubble after successful suspend
Last modified: 2006-04-11 04:13:32 UTC
I'm getting a "Suspend Failed" notification bubble popping up when I resume from a successful suspend with gnome-power-manager-2.13.92-1 in FC5 devel. This seems less than ideal :-)
Cross-filed as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183395 so we can track as a blocker for FC5
Whats the return value from pm-suspend?
No errors obviously from pm-suspend The following is in my xsession log -- WARNING: could not ask power manager to suspend - Method invoked for Suspend returned FALSE but did not set error
Then it's a HAL error surely? g-p-m is just reporting the failure of the hal Suspend method.
I know it's not the problem, but to "solve" the effect you can switch /apps/gnome-power-manager/notify_hal_error to "false".
I think it's deeper than just HAL; basically I think it's a timing with either the kernel or the system message bus daemon. Maybe the kernel is resuming processes one after one instead of in an atomic fashion... Simply try this command dbus-send --system --print-reply --reply-timeout=-1 --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0 a few times.. it will fail, yes? Of course, g-p-m shouldn't be putting up silly notifications with techno-babble such as "Suspend failed" in the first place :-) - it should be perfectly obvious to the user if suspends fails.... Btw, you want that stuff to syslog(3) and nowhere else :-)
Created attachment 60359 [details] Some suspend experiments Actually it works sometimes, most of the time in this run.. dunno why.. also tried Hibernate() that failed too. Since all other method calls in hal seems to work nicely I can do nothing but to suspect the bug is in dbus-daemon and/or the kernel. And since dbus works nicely for other time-consuming methods than Suspend() it smells like it's the kernel.. Btw, I had to delete tons of newlines that appeared in my terminal when resuming - this must be a kernel bug too... Oh.. Richard.. btw.. you _are_ setting the reply-timeout to -1 (to signify no timeouts) when doing the method call.. yes?
Just to be clear.. Suspend (aka STR) and Hibernate (aka STD) works perfectly on my system.. except for the fact that replies for D-BUS calls are lost..
>Oh.. Richard.. btw.. you _are_ setting the reply-timeout to -1 (to signify no >timeouts) when doing the method call.. yes? Not sure : this is what I'm doing. if (!dbus_g_proxy_call (hal_proxy, "Suspend", &error, G_TYPE_INT, wakeup, G_TYPE_INVALID, G_TYPE_UINT, &ret, G_TYPE_INVALID)) { Richard.
So it turns out the dbus glib bindings are broken since they do if (!dbus_connection_send_with_reply (priv->manager->connection, message, &pending, -1)) which at first glance seems alright. I actually thought -1 meant "never timeout" but we want to pass INT_MAX (which on 32-bit is only 429496 seconds, e.g. about 49 days (remember Win9x? :-)). I will complain on the dbus list; will post link to message.
I've posted a patch to the dbus list that should fix this http://lists.freedesktop.org/archives/dbus/2006-February/004358.html
Created attachment 60361 [details] more suspend experiments Wow, so with s/--reply-timeout=-1/--reply-timeout=2147483648/ things actually works very nicely even with Hibernate() - just don't hibernate for more than 49 days :-)
Hi, So is there any particular reason you block the reply for the duration of the suspend? I don't think D-Bus was ever really designed for long running methods. Maybe it would be better to reply immediately to the request and emit a signal when suspend finishes/fails? It doesn't seem that inconceivable to me that someone could hibernate a machine and come back to it a month and a half later. Giving them an error message just because they don't use their laptop often enough seems weird to me.
> So is there any particular reason you block the reply for the duration of the > suspend? I don't think D-Bus was ever really designed for long running > methods. Why would you be able to set the timeout then? Also remember that the service may queue up methods for serial processing... > Maybe it would be better to reply immediately to the request and > emit a signal when suspend finishes/fails? Nah, that's bad API design when D-BUS works perfectly well with long timeouts. It would also mean changes and special cases in the generic method dispatching code in hal and I don't really want that. > It doesn't seem that inconceivable to me that someone could hibernate a machine > and come back to it a month and a half later. Giving them an error message > just because they don't use their laptop often enough seems weird to me. Obviously D-BUS should be fixed to take a 64-bit timeout then. No, I'm not kidding actually.
Created attachment 60727 [details] [review] test patch Can you try this attached patch please? It's similar to the one shipped in Fedora, so kudos to whoever wrote the initial patch (Ray?).
Hi, > @@ -182,7 +209,7 @@ > gboolean > gpm_hal_suspend (gint wakeup) > { > - gint ret; > + guint ret; You might want to initialize ret to 0 here.
Cheers Ray, anything else you can spot?
Jeremy, does the g-p-m in rawhide (or CVS) work as expected now?
Yep, things are now working fine.