Suspend Troubleshooting

From openSUSE

Tips and tricks for debugging suspend problems

If there are problems with suspend, there is often confusion on where to start debugging and troubleshooting. Some hints are listed on this page (to be extended...)

The suspend workflow

Usually, you just click on the "suspend" button on your desktop (provided by either kpowersave or gnome-power-manager) and the machine goes to sleep. If it does not, there are several things you can do to debug the failure.

Here are some basics (this is just a raw collection right now, improvements welcome):

• if the GUI tools just seem to do nothing, try powersave -u (suspend to RAM) or powersave -U (suspend to disk). The console output of those might hint at some generic problem. If powersave also seems to not do anything, try calling pm-suspend (suspend to RAM) or pm-hibernate (suspend to disk) directly, but please read this page before doing that. pm-suspend and pm-hibernate must be run as user root.
• the "powersave" command and the GUI tools all do the same thing: they call a method in HAL which in turn calls "pm-suspend" or "pm-hibernate" from pm-utils, depending if it is suspend to RAM or to disk. The only additional thing that the GUI tools are eventually doing is to tell the "media managers" of the desktop environment to unmount all external storage etc.
• pm-suspend and pm-hibernate do various things during suspend, logging almost all of it in /var/log/pm-suspend.log. They do unload some modules if configured, prepare the bootloader (for suspend to disk), do some sanity/safety checks, eject PCMCIA cards, etc, then finally call s2ram or s2disk to do the actual suspend.
• s2disk / s2ram are low level tools and sometimes the success of those is dependant on proper preparation done by pm-utils.

Suspend Stress Testing

The Suspend_Stress_Testing article describes a method to automatically stress-test suspend, which might be handy for reproducing bugs.