Bug 725031

Summary: timeout-driven suspend fails with F15 (three blocking processes: gnome-power-manager; nm-applet; gnome-shell)
Product: [Fedora] Fedora Reporter: Jon Dowland <jon+bugzilla.redhat.com>
Component: gnome-power-managerAssignee: Richard Hughes <richard>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: rhughes, richard
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-15 13:20:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jon Dowland 2011-07-22 15:49:43 UTC 
Description of problem:

In our computing lab we want idle machines to suspend and set /apps/gnome-power-manager/timeout/sleep_computer_ac accordingly.  After the timeout, the machine does not go to sleep.

Version-Release number of selected component (if applicable):

15

How reproducible:

Always

Steps to Reproduce:
1. set gconf key above
2. wait for time out (minimum 5 minutes) without action
  
Actual results:

Machine awake; dmesg shows

[81335.731614] Freezing of tasks failed after 20.00 seconds (3 tasks refusing to freeze, wq_busy=0):
[81335.731639] gnome-settings- D f3579d30     0 21164  21153 0x00800084
[81335.731829] gnome-shell     D ee66fc7c     0 22551  21153 0x00800084
[81335.731982] nm-applet       D c0469c40     0 21205  21153 0x00800084

Expected results:

Machine sleeps.

Additional info:

The machines suspend successfully if you invoke it manually, either in the GDM splash or as a logged-in user.  The machines are using Intel Sandybridge onboard stuff, including graphics, and KMS (no user-space quirks).

We have no idea why these three processes block the suspend:  We have traced the method of suspend in pm-utils down to echo -n mem > /sys/power/state; we have traced the EBUSY return to freeze_processes:

http://lxr.free-electrons.com/source/kernel/power/process.c#L144

L144 ("Freezing user space processes  ... ") is printed prior to the failure; I haven't read beyond that to "Freezing of tasks failed after..."
Comment 1 Jon Dowland 2011-07-25 15:18:01 UTC 
As previously mentioned, a manually-invoked suspend works fine (either via echo mem > /sys/power/state, or via gdm, or gnome-shell).  An at-scheduled suspend also works:

echo 'echo mem > /sys/power/state' | at now + 1min
Comment 2 Richard Hughes 2011-11-15 13:20:56 UTC 
This should be fixed in F16, please reopen if that's not the case. Thanks.