GNOME Bugzilla – Bug 729024
Automatic suspend is very buggy, regression
Last modified: 2014-05-05 14:32:28 UTC
I have automatic suspend after 2 hours. Suspend as a feature in the kernel seems to work alright on my hardware and manually going to suspension works. With the automatic suspend, the wake up is very buggy. It wakes up and then suspends again. Sometimes I have to do this procedure three times before it starts up for real. It's kind of like you don't reset the idle timer before the check-to-suspend runs again. That's why I think this is a GNOME issue and not a kernel issue (manual suspend works and wakes up correctly). Fedora 20 with GNOME 3.12.1 COPR.
Please do: $ /usr/libexec/gnome-settings-daemon --replace --debug > ~/gsd-debug.log 2>&1 and attach the log here after one of the failed suspend resumes.
Created attachment 275404 [details] This logs a double suspend. Wake up for 2 seconds just to re-suspend.
Created attachment 275653 [details] [review] power: Cancelling a temporary unidle shouldn't set an idle mode The caller already knows which idle mode it wants us to move to. Automatically going back to the previous idle mode here would at best cause a quick spurious idle mode switch which would be immediately overriden by the caller or, at worst, we could go into suspend if the previously saved mode was SLEEP. The latter could happen on resume from suspend because there's a race between idle_became_active_cb() and handle_wake_up_screen(). If the second wins the race then we'd set a teporary unidle with the previous mode being SLEEP, meaning that when idle_became_active_cb() cancels the temporary unidle afterwards we'd immediately move to SLEEP again.
Created attachment 275654 [details] [review] power: Ensure that we run the user activity handler on resume There have been cases where the user active watch doesn't get triggered even with the reset_idletime() work-around. In any case, if we are coming out of suspend there definitely was user activity and doing this twice doesn't hurt. In particular this makes sure that we cancel any temporary unidle that might have been started while current_idle_mode was set to SLEEP and thus would take us right back into SLEEP if not cancelled. -- For good measure. See bug 729375.
Note, that even though the potential for this to happen has always been there, it wasn't a problem in practive until https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=468e1429.
Yep, because I never had this issue prior to 3.12.
Review of attachment 275654 [details] [review]: ::: plugins/power/gsd-power-manager.c @@ +2239,3 @@ + there definitely was user activity and doing this twice + doesn't hurt. */ + user_became_active (manager); No, that's really problematic because if the idle counters aren't reset, we'll never receive idle timers for automatic locking or suspend. I'd rather it stayed broken and *looked* broken, rather than making it seem like it's working.
Review of attachment 275653 [details] [review]: That looks fine indeed. It's only ever called with FALSE from idle_became_active_cb(), and that will reset the mode to GSD_POWER_IDLE_MODE_NORMAL.
Ok, left the other one out. Attachment 275653 [details] pushed as 9cc1fe7 - power: Cancelling a temporary unidle shouldn't set an idle mode