Triage and Debug of Kernel Hibernate Resume apport bugs

This page is aimed to help you do initial triage and debug of hibernate/resume bugs as reported by apport. This page presents some background information as to how the reporting works, and then will take you through a series of debug steps recommending information and data which will need to be collected.

The primary source of reports of hibernate failures arrive via apport. Apport checks at boot time whether there was a hibernate in progress, if we are booting normally then that was never resumed and therefore has failed. This means that the failure may have occurred some time before the report is generated. Bear this in mind when answering the questions below.

Bug Validation

Before gathering information on the bug you could consider the questions in this section which will help weed out false reports and duplicates.

Is this really a failure?

If it is the case where the user has an encrypted swap, hibernation will currently fail. This is a known issue. See below for more information.

Is this a repetition of a previous failure?

If this is another occurrence of a previous reported failure it is best to mark the new bug a duplicate of the first using the Mark Duplicate link on the bug report.

Information Gathering

At a very minimum every hibernate/resume bug should contain the answers the questions in this section before being considered Triaged.

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.

Please indicate in the bug whether it is a hibernate or wakeup failure and how you determined this.

Is it reproducible?

Is the problem reproducible. If you do say 10 hibernate cycles does the problem occur every time, 1 in 5 etc. Do the symptoms vary at all?

Please indicate in the bug how and what you tested.

Did it work before?

Has this hibernate ever worked in the past. If it has which kernel release did it work on?

Please indicate in the bug whether it worked, and if so include the contents of /proc/version_signature from that release (or the Ubuntu version number if you do not have it).

Do you end up with flashing Caps Lock light or similar?

If you have a flashing Caps Lock light then very likely you are experiencing a kernel panic.

Please indicate that in the bug.

Hibernate specific information

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:

1. dmesg

2. cat /proc/cmdline

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

Other information

Please include any information as to the circumstances leading up to this failure, anything unusual for example did you see any error messages?

Debugging Hibernate

Failure due to encrypted swap

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

Users installing from Ubuntu 9.10 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 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:

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

This will select a much smaller font so that you can see more messages should they come out, and then initate the hibernate.

To help us investigate the problem please use the following debug test method and report results in the bug. Common method is to take photos of the screen & attach dmesg output to the bug report.

Per sub-system hibernate testing

Again from VT-1 (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

If you cat /sys/power/pm_test and cat /sys/power/disk it 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.

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. If nothing else in this article solves that issue, or the text above just doesn't apply to your particular setup, one may try disabling Kernel Mode Setting.

Edit your 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

See also

• KernelTeam/SuspendResumeTesting

CategoryKernel CategoryDebugging