Introduction

This page is to help you debug and triage hibernate/resume bugs. The two types of reports are those generated via apport, and manually reported via ubuntu-bug linux. For apport reports, apport checks at boot time whether there was a hibernate in progress, if the computer boots normally then it never resumed and therefore failed. This means that the failure may have occurred some time before the report is generated. Bear this in mind when debugging and triaging.

Known issues

Failure due to encrypted swap

https://help.ubuntu.com/community/EncryptedHome

Users installing and selecting the Encrypted Home option will automatically have encrypted swap space. Other users may have also ran sudo ecryptfs-setup-swap. It is important to note that hibernation will work with an encrypted swap but resume from hibernation will fail. There are ways around this, but they involve choosing a password to use for your encrypted swap and entering that password every time you boot your system, and sharing that password with anyone else that might want to resume the system. This is a known, wishlist issue that we hope to solve. If you happen to report or triage this type of issue, please tag the bug encrypted-swap. For triagers, posting the following comment to a bug may help:

Information to provide in a bug report

At a minimum every hibernate/resume report should contain responses to each item in this section before being considered Triaged.

1. Is this really a failure?
   • If it is the case where the user has an encrypted swap, hibernation will currently fail as previously noted.
2. Is it reproducible? If not, how often would it be reproducible?
3. Did it work before on a prior kernel in the same release, or prior release?

4. Do the symptoms vary at all between hibernation attempts? For example, one time WiFi didn't work, but another a kernel error shows on the screen.

5. Do you end up with a flashing Caps Lock light?
   • If you have a flashing Caps Lock light then very likely you are experiencing a kernel panic.
6. Please advise on how the computer hibernated, and resumed specifically. For example:
   • Executing at a terminal pm-hibernate
   • Shutting the lid of your laptop, which is set to hibernate on close.
   • Clicking the word Hibernate in the GUI.
   • The computer hibernated automatically on inactivity.
7. Did the machine break while going into hibernation or waking up?
   • It is very important to know whether the problem occurs on the way into the hibernation state or on the way out. If the machine never makes it to hibernate, but instead wakes up or powers off incorrectly, that is a hibernate failure. If the machine wakes back up from hibernate but then takes you to the login prompt or crashes after that then it is a resume failure.
8. Did you see any error messages leading up to the failure?
9. For resume from hibernate failures, please include the output from the following commands from the boot following the hibernate, this includes information on the search for the resume device, etc.:

   • dmesg

   • cat /proc/cmdline

   • cat /etc/initramfs-tools/conf.d/resume

10. The information as applicable below.

Hibernating from text mode

The first step for debugging hibernate is to determine if the issue occurs when triggered using the pm-hibernate command. If possible you should reboot the system with the no_console_suspend boot parameter. See DebuggingKernelBoot for instructions on how to modify boot parameters. You should then switch to VT1 by pressing Ctrl-Alt-F1. Login at the prompt there and then run the following commands:

setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz
sudo pm-hibernate

Common method is to take photos of the screen and attach the dmesg output to the bug report.

Dead, blank, or black screen on resume

In some cases, a machine can hibernate just fine, and resume without issue, with the exception of waking up to a blacked-out screen. In other words, the computer is running just fine, but the display appears dead. One thing to try is disabling Kernel Mode Setting. One may do this by editing the grub configuration:

     sudo nano /etc/default/grub

Find the line reading:

     GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Add nomodeset to the end, inside the quotes:

     GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Exit from nano and save the file. Make grub aware of the new changes:

     update-grub2

When that exits, reboot the computer normally, then test hibernate. This change will persist across reboots unless you explicitly revert it. In some cases, this will also fix another issue where the screen doesn't dim after a period of inactivity like it should, assuming it is otherwise configured to do so in your desktop environment.

Per sub-system hibernate testing

Again from VT1 (see above for instructions), first reduce the size of your font with the following commands:

setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz

There are three tests listed below:

• "devices" test mode in "platform" mode of hibernation.
• "core" test mode in "platform" mode of hibernation.
• "core test mode in "reboot" mode of hibernation.

The test modes are as follows:

• core: Test the freezing of processes, suspending of devices, platform global control methods(*), the disabling of nonboot CPUs and suspending of platform/system devices.
• devices: Test the freezing of processes and suspending of devices.

Performing cat /sys/power/pm_test and cat /sys/power/disk will list the modes that it supports.

Then run the following commands:

sudo -i

lsmod > lsmod.output.txt

echo devices > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state
dmesg > /tmp/dmesg-devices-platform.txt

echo core > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state
dmesg > /tmp/dmesg-core-platform.txt

echo core > /sys/power/pm_test
echo reboot > /sys/power/disk
echo disk > /sys/power/state
dmesg > /tmp/dmesg-core-reboot.txt

Please collect the lsmod, full dmesg output files from the failing boot/tests, and attach to the bug report. This includes significant information about the search for the resume device.

Please report whether you got any additional messages. Digital photos of the screen are a sensible way to get this into the bug.

CategoryKernel CategoryDebugging