如何調試Suspend-Resume相關的Bug

在Linux系統中，Suspend-Resume是一個複雜的過程，其涉及到BIOS、Kernel、Graphic驅動以及相關的應用程式。本文将介紹如何調試Suspend-Resume相關Bug，如何縮小引起Suspend-Resume失敗的範圍。

在此之前，我們必須Kill所有使用/proc/acpi/event的程序，例如：gnome-power-manager。

1.        運作：lsof /proc/acpi/event；

2.        Kill以上列出的程序；

需要注意一點：

1.        分别在Console模式（Level 3）和X模式（Level 5）執行Suspend/Resume。如果隻在X模式測試失敗，說明該BUG是與X相關的，那麼我們就檢查DDX驅動，XServer或者其他與Suspend-Resume相關的應用程式，例如：pm-suspend等等。如果在兩種模式下，測試都是失敗的，那我們調試的重點放到Console模式；

2.        在Suspend之前和Resume之後分别執行：dmesg；

3.        為了縮小範圍，我們可以嘗試删除一些核心子產品。比如：如果删除了Intel的i915驅動，系統能夠正常Suspend/Resume，那麼，我們有理由懷疑i915驅動是該BUG的罪魁禍首；

S3 Suspend (Suspendto RAM):

檢查Resume Hang是否由Graphic驅動導緻的

1.        運作：dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after

2.        按電源鍵，觀察系統是否可以正常Resume;

3.        如果無法正常Resume，那麼重新開機系統，檢查檔案dmesg_after;

4.        如果檔案dmesg_after存在，說系統可以正常從BIOS中Resume回來，那麼該BUG很有可能是由Graphics導緻的；否則，該BUG就和Graphics不相關，需要從BIOS角度去查找原因；

在Suspend/Resume的時候，忽略BIOS

1.        在Kernel的配置檔案中，将“CONFIG_PM_DEBUG”給enable，這樣我們就可以使用/sys/power/pm_test;

2.        運作：echo core/processors/devices > /sys/power/pm_test;

3.        運作：dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after;

4.        等待5秒，觀察系統是否可以正常Resume;

5.        如果系統無法正常Resume, 那麼該BUG很有可能是由Graphics導緻的；

S4 hibernation(Suspend to Disk)

如果在kernel啟動的時候，Resume失敗了，那麼我們試試在boot選項中增加“resume=/dev/xxxx”(xxxx表示swap分區)；

檢查該Bug是否在Console模式和X模式都是一樣失敗的：

1.        啟動系統至Console模式（Level 3）；

2.        運作：echo disk > /sys/power/state;

3.        按電源鍵，觀察系統是否可以正常Resume;

4.        如果系統可以正常Resume，說明該BUG可能與Graphics驅動相關；

5.        如果系統無法正常Resume，說明該BUG可能與Linux Kernel相關；