GNOME Bugzilla – Bug 486138
suspend after resume from hibernate
Last modified: 2009-03-04 15:16:09 UTC
when g-p-m hibernates because the machine is idle, it resumes successfully, but immediately afterwards suspends. I'll attach the output of gnome-power-bugreport.sh and a gnome-power-manager --no-daemon --verbose log from such a sequence of events this was first reported here: https://bugzilla.redhat.com/show_bug.cgi?id=329541
Created attachment 97142 [details] gnome-power-bugreport.sh output
Created attachment 97143 [details] gnome-power-manager log
I can confirm the same behaviour with: Debian/sid kernel 2.6.23 I, too, have Oct 13 14:32:39 mithrandir gnome-power-manager: (norbert) Resuming computer Oct 13 14:32:39 mithrandir gnome-power-manager: (norbert) suspend failed Oct 13 14:32:55 mithrandir kernel: Stopping tasks ... done. Oct 13 14:32:55 mithrandir kernel: Suspending console(s) ... suspending stuff... Oct 13 14:32:55 mithrandir kernel: Coming out of suspend... ...
One more thing: I tried with plain s2ram call and this didn't exhibit this behaviour. So it seems to be related to g-p-m and not the suspend action itself.
I'm looking at this now..
Created attachment 97309 [details] [review] Proposed patch Got it; it's another case of call-sites passing NULL as the GError** pointer and then we freak out because of timeouts. The attached patch fixes this up. Please commit. Thanks.
I confirm that the above patch fixed the problem for me. I recompiled the debian/sid package including this patch and closing the lid and waking the laptop up did not go into the 2 times loop. Thanks a lot.
Hmm, that was too early a confirm. Today I again had problems: Oct 18 06:37:24 mithrandir gnome-power-manager: (norbert) Suspending computer be cause the lid has been closed on battery power ... Oct 18 07:12:39 mithrandir kernel: Back to C! ... resuming loads of stuff... Oct 18 07:12:40 mithrandir gnome-power-manager: (norbert) Resuming computer Oct 18 07:12:40 mithrandir gnome-power-manager: (norbert) suspend failed ... Oct 18 07:12:46 mithrandir kernel: PM: Preparing system for mem sleep Oct 18 07:13:03 mithrandir kernel: PM: Entering mem sleep Oct 18 07:13:03 mithrandir kernel: Suspending console(s) .. Oct 18 07:13:03 mithrandir kernel: agpgart-intel 0000:00:00.0: LATE suspend Oct 18 07:13:03 mithrandir kernel: Back to C! Oct 18 07:13:03 mithrandir kernel: agpgart-intel 0000:00:00.0: EARLY resume ... Furthermore, after this I can suspend as before with closing the lid, but the gnome session is not locked anymore. Note that when waking up THE FIRST TIME this is the only time this happens. And also only at the first time there is a message that "suspend failed". Hmm, anything more I can do to track this down?
Anything new here that I can do/test? As said, I tried the submitted patch with the current debian packages without success, so is there any chance for another debugging?
I (and lot's of other users) have the same problem on Ubuntu. I made the following comment there on the bugreport in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116826 . It was recommended to post that comment here too. To clarify: In ubuntu 7.10, there is only a option for hibernation in the gnome-power-manager dialogue, I don't know if this is also true for the original version. It looks like gnome-power-manager has two options, one is available as a setting in the menu, the other one is only available in the gconf-editor.In the gnome-power-manager settings dialog, you can set the PC's timeout for initiating hibernate. However, there is also an option in the gconf-editor for gnome-power-manager, that handles the sleep timeout. In my fresh install of Ubuntu, I putt the hibernate function on 11minutes, and the sleep function appears to be sett at 120 seconds. Probably this is going wrong: after 120 seconds, the PC starts sleep mode. When you start it again after the 11 minutes have elapsed, it somehow makes the error that the 11 minutes should be counted too when the system is at sleepmode and thus hibernating needs to be activated.I now have put hibernation to off, and sleep to 180s, will report later if this seems to be working. [..]
It appears that I have been wrong in my assumption that their were two timers: one for hibernation and one for sleepmode. The gconf key for sleepmode_ac timeout is the one that gets used when setting the hibernation timeout in the G-P-M settings dialogue. Still, lots of users are reporting problems in Ubuntu.
This has been fixed (for two people) in 2.22 (Ubuntu Hardy).
I'm still seeing a similar problem with 2.22.1 on Ubuntu 8.04. I've recorded a log which seems to demonstrate the problem, i.e.: 1. The system being idle for the specified period of time, and gpm deciding to sleep 2. The system resuming some 10 hours later 3. gpm detecting a failure to suspend, though in fact it was suspended for 10 hours 4. gpm trying hibernation instead, still trying to satisfy the original request to suspend Notably, this doesn't seem to happen if the system is only suspended for a short time, so this seems to point to a timeout similar to that described above. The complete log is attached to https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/136871 and I will attach here as well.
Created attachment 112893 [details] gnome-power-manager log (mdz)
Interesting. This is likely to be related to the false "Hibernation failed" warning we see for a long time, and that now results in a sound when resuming.
The relevant snippet from the log is: [system_timer] gpm-idle.c:171 (23:38:29): System idle timeout [gpm_idle_set_mode] gpm-idle.c:98 (23:38:34): Doing a state transition: 3 [idle_changed_cb] gpm-manager.c:876 (23:38:34): Idle state changed: SYSTEM [gpm_inhibit_has_inhibit] gpm-inhibit.c:336 (23:38:34): Valid as no inhibitors Saving to syslog: Suspending computer. Reason: System idle.[gpm_info_event_log] gpm-info.c:594 (23:38:34): Adding 5 to the event log [gpm_control_get_lock_policy] gpm-control.c:389 (23:38:34): Using custom locking settings (1) [gpm_screensaver_lock] gpm-screensaver.c:250 (23:38:34): doing gnome-screensaver lock [gpm_control_suspend] gpm-control.c:439 (23:38:34): emitting sleep ** (gnome-power-manager:28309): WARNING **: Method failed (An unknown error occured) [gpm_control_suspend] gpm-control.c:447 (09:37:37): emitting resume [...] [gpm_control_suspend] gpm-control.c:451 (09:37:37): emitting sleep-failure [...] [idle_do_sleep] gpm-manager.c:813 (09:37:37): cannot suspend (error: General failure: An unknown error occured), so trying hibernate
I can confirm this bug with Ubuntu Hardy Heron 8.0.4.1 LTS on a HP 6910p laptop and the ATI Catalyst 8.10 FGLRX drivers installed. Interestingly, this behaviour was not seen with the 8.9 FGLRX drivers. Just to be explicit: Allowing the machine to automatically suspend (after 1 hour) works well. In the AM, starting the machine from the suspended state bring the machine back, BUT then it immediately HIBERNATES. Resuming the machine from Hibernation works perfectly and machine behaves as it should. Interestingly this DOES NOT happen when I manually cause the machine to suspend (close laptop lib; Fn+F2; or choose SUSPEND from GPM applet). The machine suspends and the next AM, I can restart the machine and all is well - no inadvertent HIBERNATION behaviour. Q: What debugging files do you need to diagnose this bug? - CH
Andor J Kiss: Any news on that? I could not find any people but you that experienced this bug for 5 months. Seems to have been fixed, at least for most of us.
FWIW, I haven't seen this happen on Ubuntu 8.10
How was this bug fixed eventually? In Ubuntu we have one user saying it's reappeared recently (g-p-m 2.22), though during a period while g-p-m was not updated. Can it be related to D-Bus?
Possibly; I think that's what it was a while back.
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.