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.
Failure due to encrypted swap
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:
Thank you for taking the time to report this bug and helping to make Ubuntu better. It is currently a known issue that Hibernation will fail to resume due to an encrypted swap. Please refer to https://help.ubuntu.com/community/EncryptedHome for more information. We will tag this bug "encrypted-swap" so that we can track this issue going forward and possibly request additional testing. Thanks in advance for your patience and cooperation.
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.
- Is this really a failure?
- If it is the case where the user has an encrypted swap, hibernation will currently fail as previously noted.
- Is it reproducible? If not, how often would it be reproducible?
- Did it work before on a prior kernel in the same release, or prior release?
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.
- 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.
- 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.
- 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.
- Did you see any error messages leading up to the failure?
- 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.:
- 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:
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:
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:
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.
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues - Best practices to debug hibernate issues
DebuggingKernelHibernate (last edited 2016-12-27 21:20:01 by penalvch)