Feedback

Your feedback is important to keep improving our website and offer you a more reliable experience.
Home / Intel® Graphics for Linux* / Documentation / Development / Intel® Graphics for Linux* - How to debug suspend-resume issues

How to debug suspend-resume issues

Published by:
Last modification:
Mar 01, 2015

The purpose of going through the steps below is to help narrow down the root cause (BIOS? Kernel? Graphics driver?) of the suspend/resume failure and provide more info for debugging.


Prerequisite: No processes using /proc/acpi/event (which might be used by, for example, gnome-power-manager, to interfere with some ACPI related actions, like pressing the power button).

1. Get the process id by "lsof /proc/acpi/event".

2. Kill these processes.


Notes:

1. Perform suspend/resume test under both text console mode (init level 3) and X mode (init level 5) to see if it's X specific. If they are with the same failure, let's focus on text console mode and just provide logs under that condition.

2. Provide the following logs before and after suspend/resume:

  • dmesg output
  • intel_reg_dumper output (using reg_dump tool in xf86-video-intel source package)
  • intel_gpu_dump output (see this guide)

3. To narrow down the issue, try removing modules before you suspend. This can help determine which module is responsible for a suspend or resume failure. For example, if you remove the b43 module and then suspend/resume works, there's likely a problem with either b43 or the wifi stack.

4. If you remove i915 module, and suspen/resume still fails, it's likely not our drm graphics driver bug. Please file the bug at bugzilla.kernel.org, select the component "Power Management - Hibernation/Suspend", and CC rafael.j.wysocki@intel.com.


S3 suspend (a.k.a Suspend To RAM):

a. Check if the resume hang is caused by graphics driver:

1. Run: dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after

2. Press the power button to see if the machine can be resumed.

3. If it can't be resumed, reboot the system then check if the file "dmesg_after" generated.

4. If dmesg_after exists, it means that the system can be resumed from BIOS, so it's likely to be a graphics issue. Otherwise, it's not related to graphics and don't report it to freedesktop.org bugzilla.

b. Suspend/resume by skipping BIOS:

1. Enable "CONFIG_PM_DEBUG" in kernel configuration, so that we can use /sys/power/pm_test.

2. Run: echo core/processors/devices > /sys/power/pm_test

3. Run: dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after

4. Wait for about five seconds and see whether it can be resumed correctly.

5. If it can't be resumed correctly, it may be graphics driver bug. This info is helpful to narrow down the issue.


S4 hibernation (a.k.a Suspend To Disk):

If resume fails at kernel booting stage, try adding boot option "resume=/dev/XXXX" (XXXX means the swap partition).

Check if hibernation under console mode has the same failure as in X mode.

1. Boot the system into init level 3 (text mode).

2. Run: echo disk > /sys/power/state

3. Press the power button to see if the system can be resumed correctly.

4. If it can be resumed normally, the issue may be related to the graphics driver.

5. If it can't be resumed normally, the issue may be related to the Linux kernel.

 

Was this information helpful?