I have experienced two recent situations where pm-suspend (a.k.a. “sleep” or suspend-to-ram") would not execute properly.
I have a desktop and a laptop, both running
SuSE 11.3
kernel 2.6.34.7-0.5-desktop
KDE 4.5.2
I have the following setup for pm-utilities
cat /etc/pm/config.d/cjm_suspend_tweaks
# read the s2ram and pm-utils items on SuSE
S2RAM_OPTS="-f -a3" # options that are passed to s2ram. See the Suspend to RAM page for more information.
Suspend has been working well on both machines until recently, it seemed the 2.6.34.7-0.5 update might have been a contributor or cause, however I have been doing a lot of other playing so that is inconclusive.
Desktop:
My system is built on an ASUS M2A-VM HDMI motherboard and I use the on-board ATI RS690 device(ATI Radeon X1200) for display. This is an ATI “legacy” device but the open source radeon driver works well.
There is a BIOS setting for the amount of shared DRAM allocated to the video device.
Until recently, I had this setting at 256Meg. The driver and pm-suspend worked well.
Yesterday, I was experimenting with a two head (dual monitor) configuration and found that I needed to set the “UMA shared memory” (the BIOS setting)to at least 512Meg for the dual head configuration to work completely. With only 256Meg allocated, the dual displays were active but only half the second monitor would display anything active(the wallpaper did display).
Later in the day, after returning to a single display, I found that the system would not wake up properly. Suspend hooks would run, the system go to sleep, but on wake up, just a black screen.
Returning the BIOS setting to allocate only 256Meg has me back to pm-suspend working “normally” and well.
I can’t determine if this is a BIOS issue, a radeon driver issue, an s2ram issue or something else. I did not get a chance to try the other “s2ram -f - **” options to see if the larger memory config needed a different setting.
This is just a heads-up or debug starting point for someone with a similar setup.
Both Laptop and Desktop:
On both my desktop(set for UMA=256Meg, see above) and on my laptop (an HPDV7, runs latest fglrx), pm-suspend has been intermittent - goes to sleep normally sometimes, starts to sleep but then comes back up at other times.
When suspend fails to execute properly, a look in
cat pm-suspend.log
.......
Sun Oct 31 12:58:59 EDT 2010: performing suspend
INFO: using user-supplied options: S2RAM_OPTS='-f -a3' for suspending.
switching from vt7 to vt1... succeeded
fbcon fb0 state 1
* error message in here about s2ram.so Device busy*........
fbcon fb0 state 0
switching back to vt7... succeeded
......
I do not have an exact copy of a pm-suspend failure log, looks something like the above.
When I see this failure, a look in
(as root) vi messages
...............
Oct 30 08:06:22 PVE-LinuxSRV5 kernel: 215.301190] PM: Syncing filesystems ... done.
Oct 30 08:06:22 PVE-LinuxSRV5 kernel: 215.463639] PM: Preparing system for mem sleep
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 215.463986] Freezing user space processes ...
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473179] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze):
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473223] ksysguardd D ffffffff8160aa60 0 4263 4216 0x00800004
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473228] ffff88020f4a9b18 0000000000000086 ffff88020f4a9aa8 ffff88020f4a9fd8
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473234] 0000000000013e40 ffff88020f4a9fd8 ffff88020f30c1c0 0000000000013e40
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473239] ffff88020f4a9fd8 0000000000013e40 0000000000013e40 0000000000013e40
Oct 30 08:06:42 PVE-LinuxSRV5 kernel: 235.473244] Call Trace:
.....
I run a desktop widget on both systems that run on top of ksysguardd to display cpu and disk activity. It seems more prone to crashing of late. Closing that widget resolved the pm-suspend issue. I have also had a dolpin hang produce the same result(dolphin hung because I turned off an nfs server it was viewing).
If pm-suspend misbehaves for you, have a look in /var/log/pm-suspend.log, then in /var/log/messages for a hint as to what is hanging up the “Freezing of tasks” process.
Happy hunting/debugging.