Linux操作系统硬件稳定性指南（上） （3）

抢救 CPU

如果您的 CPU 在重负载之下正发生随机的断断续续的错误，可能您的 CPU 根本没什么问题 -- 可能只是冷却不当。您可以检查下列内容：

您的 CPU 风扇是否已插上？

它是否能相对地避免灰尘？

通电时风扇确实旋转（并以适当的速度旋转）吗？

散热片在 CPU 上固定好了吗？

在 CPU 和散热片之间有导热胶吗？

您的机器通风情况足够好吗？

如果一切正常，您可能希望让此打开的机器返回到内核编译测试。请让内核编译进行大约五分钟时间，然后将手放到这个正在运行的机器中并触摸周围的供电设备的外部金属保护外套。然后，用指尖小心地测试散热片的温度。如果异常地热，那么很可能您的散热片／风扇组合相对于您的特定 CPU 来说不够强劲。在这种情况下，升级您的系统冷却硬件 -- CPU 尚未遭受任何永久性损坏并且仍然可发挥作用。

最终 CPU 测试

内核编译测试是测试 CPU 稳定性的一个很好的方法，但还有一个更极端的 CPU 测试方法，或许您希望使用。我将这种方法保留到最后，是因为如果 CPU 只粗略地冷却过，这种特殊的测试可能会真的使其过热，理论上会对 CPU 造成永久性损坏。这种测试倾向于那些通过内核测试，没有什么问题的系统 -- 那些您希望确保即使 CPU 负载达到极限也能轻松处理的系统。如果您的 CPU 已经过适当地冷却，将会通过这个测试，如果没通过，则需要进一步冷却。

要执行 "最终" CPU 测试，所做的第一件事是转到 Lm_sensors 页（请参阅参考资料）并下载 lm_sensors 软件包。源 tarball 包含各种内核模块，这些模块结合了几乎已内建在所有当今主板上的健康监视功能。一旦正确安装了软件包并且装载（使用 prog/detect/sensors-detect 脚本指出装入哪些模块）合适的模块，您将看到一些新文件和目录出现在 /proc/sys/dev/sensors 下。这些文件包含方便的信息如 CPU 风扇速度、CPU 和主板温度读数以及主板电压读数，所有这些信息都会实时更新。由于我配置此软件包收到了较好的效果，所以我推荐您配置此软件包作为模块编译并使用 sensors-detect 脚本来指出引导时装入哪些模块。

一旦装入了 lm_sensors 模块，我推荐您安装一个图形 CPU／传感器监视器，它使您能够实时观察 CPU 负载和温度而无须重复地在 /proc/sys/dev/sensors 中 "cat" 文件。出于这个目的，我使用一个称为 gkrellm （请参阅参考资料）的很小的程序。这是我的 gkrellm 应用程序的快照，用来监视 CPU 使用情况、主板温度设置和其它一些事情：

还有其它与 lm_sensors 兼容的图形监视软件包可用；您会发现在 lm_sensorshome 主页的"链接"部分上，列出了许多这种软件包。

最后一步准备步骤是下载 cpuburn 程序（请参阅参考资料）。这个方便的小程序使用机器指令的手工组合为您的特定 CPU 施加最大的压力 -- 甚至比重复的内核编译的压力还要大一些。档案中包含的多种小程序被定制为设置 P5 和 P6 级处理器，和 AMD K6 的特殊版本。一旦已将 cpuburn tarball 解包，请读 README 文件；它说明如何编译所包含的汇编源文件。完成这些后，您将拥有自己的 cpuburn 小程序。

现在，等待测试。我通常启动我的图形传感器监视器，然后作为 root 启动 cpuburn 程序。然后，观察 CPU 温度读数上升并变稳，让 cpuburn 保持运行大约一个小时。如果重复这些步骤而且 CPU 温度持续上升到异常高的温度（160 华氏度左右将被认为是“异常”高），那么您的 CPU 冷却系统需要大的调整。如果机器崩溃或锁定，或 cpuburn 进程死掉，那么您的 CPU 冷却需要改进 -- 或者可能您的特定 CPU 只是简单地不符合“规范”。您可以使用 CPU 温度读数作出判断。但如果一切顺利，那么您的系统将可应付所有的挑战。大约一小时后，您可以继续进行并杀死 cpuburn 程序，恢复正常操作。

内存测试

拥有一个完全可靠的 CPU 的确很重要，但拥有一个非常稳固的 RAM 芯片也很重要。有些人认为 SIMMS 和 DIMMS 永远不会坏，从不需要测试。不幸的是，这种想法是错误的 -- 坏的内存非常普遍，我们都需要注意内存问题。另有一些人认为如果可能有坏的 RAM，引导时 BIOS 内存检查会检测出所有的 RAM 错误。这种想法也是错误的；BIOS 内存检查检测不到许多坏的 RAM，所以不要让 BIOS 检查给您一种安全的错觉。

坏内存症状

好的，这里有一个坏的 RAM，或许现在正在您的机器里面。这里有一些警告迹象指出您的机器包含坏的 RAM：

当同时装载大量的程序时，不时有某个程序无明显原因地死掉。

不时地，打开一个文件时，显示文件被毁坏。如果稍后打开，文件看起来又好了。

当抽取 tarball ("tar xzvf") 时，tar 频频报告 tarball 已毁坏。过几天再次尝试抽取 tarball 时 tar不报告任何错误。相似的问题也会发生在 gzip 和 bzip2 上。

如果您正经历类似这样的问题，可能是系统 RAM 有缺陷。您将确定要使用下列方法测试您的 RAM。即使您没有经历过这种问题，好好地测验一下系统的 RAM 仍不失为一个好主意，可确保您将来不会被意外的 RAM 突发问题所困扰。下面是测试方法。

memtest86

我们很幸运，有一个安装在可启动软盘上的基于 Linux 的优秀的内存测试程序。它的名称为 memtest86 （请参阅参考资料获取该程序）。创建一个内存测试软盘很简单。首先，下载 tarball。然后，将档案解包并构建二进制磁盘映象：

# tar xzvf memtest86-2.5.tar.gz
# cd memtest86-2.5
# make

然后，将一张 3.5 英寸空白磁盘插入到软盘驱动器，并输入：

# make install

仅几秒钟后，就会有一个可爱的小内存测试程序在您的 3.5 英寸磁盘上，准备被引导。执行此测试的最好方法是当您的机器可空闲至少六小时时，找一些时间 -- 在上床前（或离开工作时）开始测试是一个好主意。要开始测试，请将 3.5 英寸磁盘放在驱动器中重新引导您的机器。当系统引导时，memtest86 程序将立即启动：memtest86 正在测试开发机器上的 RAM。主要的内存突发问题（比如“死亡”位）将在几秒钟内检测出来。由特定位模式触发的故障（不幸的是这种故障相当普遍）可能几个小时也无法检测出来，但最终应该会检测出来。memtest86 一检测到缺陷位，就将在屏幕底部显示一条消息 -- 测试将继续。当早上打开监视器时，您会发现测试已完成，如果在屏幕上看不到任何警告信息，那么 RAM 确定是好的。但是，如果您继续遇到“坏内存症状”部分列出的问题，那么您的 RAM 可能有突发性问题（这种问题很少发生），可能仍需换掉此 RAM。

解决 RAM 问题

我希望您所有的 RAM 都运行良好。然而，如果不幸您的 RAM 有问题，可能没有全部坏掉 -- 您仍可以采取一些措施来“修复”坏的 RAM。首先我建议您查看 BIOS 安装程序并看一下内存设置。一些 BIOS 安装程序有称为“Turbo 方式”的内存选项 -- 显然，如果您启用了一些与此类似的选项，则应该禁用此选项。还有可能您的 BIOS 内存定时设置得不正确 -- 您可以尝试调整它们（增加刷新率、降低 CAS 设置）并重新运行 memtest86 看看这些问题是否已解决。

如果内存测试仍旧发现错误，那么此时您应该找到错误的 SIMM 或 DIMM 并将其从您的机器中除去。如果您安装了多个内存模块，那么您要仅安装一个模块（或如果您有 SIMMS，则可以安装两个模块）并运行 memtest86。轮番测试所有的模块后，您能够确定有缺陷的模块 -- 不必将好的内存模块也扔到废物堆里。