如何在Linux上调试Suspend-to-RAM问题？

我希望获得有关如何调试暂挂到RAM问题的基于经验的建议。针对我的情况的建议（在下面进行详细介绍）会很不错，但是我也对如何调试此类问题的一般建议感兴趣。

问题：

通常，当我尝试挂起计算机时，它陷入“未挂起但未唤醒”状态。通常，屏幕会是全黑的，但有时屏幕上会显示以下错误消息：

GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0) 

同样，这种状态也将伴随着球迷大步前进。使它脱离此状态的唯一方法是手动关闭笔记本电脑的电源。

一些信息

$ uname -a
Linux baltar 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 10.10
Release:    10.10
Codename:    maverick

我查看了/var/log/dmesg和/var/log/pm-suspend.log，但是我不知道自己在寻找什么，所以什么都没有。我不确定是否相关，但是我确实在中找到了很多以下内容/var/log/kern.log：

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600

您有Intel图形芯片组吗？我在运行Ubuntu 10.10的ThinkPad X200上遇到了同样的问题，这种变通办法（从2008年开始！）为我修复了该问题：http : //ubuntuforums.org/showpost.php?p=6105510&postcount=12

PM_DEBUG和PM_TRACE显然是目前最深入的调试工具。当您从更高级别的日志中没有任何意义的时候，AFAIK是遇到可怕的“简历上的神秘黑屏”症状时可以依靠的唯一机制。大多数情况下，我们要处理的是一个非常微妙的损坏的设备驱动程序。您也可以在内核错误34682上查看我的Broadcom brcmsmac无线驱动程序调试传奇，以了解内核开发人员的建议和期望。

我怀疑该问题可能是由于BIOS无法正确报告其实际使用的lowmem。

默认情况下，此选项有效：

memory_corruption_check_size=64K

您可以尝试将其设置为更大的值，以使内存损坏扫描程序可以检查更大一部分的lowmem。

在以下位置查找“ memory_corruption_check_size”

• http://lxr.linux.no/#linux+v2.6.35.7/Documentation/kernel-parameters.txt

等等

我很想知道您的发现，如果有的话。

我在该领域的工作经验是Windows CE，而不是Linux。

在挂起/恢复周期中，操作系统将逐渐关闭操作系统功能，从而限制了您获取有关使用操作系统功能情况的准确可靠信息的能力。此外，您的监视连接可以（例如，如果问题与时间相关）会改变结果。

首选工具从在高端与OS的C / C ++调试器连接开始，在非常低的级别，通过串行端口/ POST代码或在非X86硬件JTAG调试器或等效设备上发送数据。最终结果是花费大量时间来计算代码流，并找出行为与正常行为不同的地方。在这一点上，修复通常是显而易见的。保持良好的笔记，一次进行一次更改。

花费了6个星期的时间，我们才发现Windows CE的开机问题。我们有一块PC104处理器板，我们可以将其关闭10或60秒钟，然后再正常上电。但是，如果断开电源25秒钟，则无法开机。事实证明，我们有足够的电容来保持DRAM内容完整无电约20秒钟，因此在短时间关闭电源后，Windows CE认为它正在从挂起状态恢复。保留所有内存后，它实际上将成功执行恢复，而当内存部分损坏时，它将在恢复过程中变得相当混乱。

祝好运。