Linux 负有盛名的特点之一是其非凡的稳定性。然而， 如果您的硬件有缺陷或配置不正确，即使是世界上最稳定的操作系统也不会对您有什么帮助。 本文中，Daniel Robbins 将告诉您如何诊断和修理 CPU 片，并告诉您如何测试 RAM 缺陷。在本文结束之前， 您将拥有确保您的 Linux 系统的稳定性达到尽可能好的技能。
在 Linux 世界中，我们中的许多人已遭受过令人深恶痛绝的硬件问题之苦。许多人已经有了 Linux 机器、安装了最喜欢的分发软件、编译并安装了一些附加应用程序并且使各个部件都运行顺利，只是为了确定新系统中有一个 (argh)！致命的硬件错误？症状是随机分段错误、数据毁坏、硬锁定、还是丢失数据都是不相关的 -- 硬件故障使通常情况下可靠的 Linux 操作系统几乎无法顺利运行。本文中，我们将深入探讨如何检测 CPU 和 RAM 问题 -- 在执行一些破坏性严重的操作之前允许更换缺陷部件。
如果您正遭遇不稳定问题并且猜测该问题与硬件有关，我鼓励您测试 CPU 和内存以确保它们工作正常。但是，即使您尚未遇到这些问题，执行 CPU 和内存测试仍不失为一个好主意。在测试 CPU 和内存中，您可能会检测到硬件问题，它可能会在某个不适当的时候给您带来麻烦，并可能已经造成了数据丢失或让您花了数小时却搜索不到问题的根源。正确地，前瞻性地应用这些技术可帮助您避开这些令人头疼的问题，并且如果系统通过了测试，您即可放心，系统是符合规范的。
CPU 问题
如果您有一个非常糟糕的 CPU，您的机器可能无法引导 Linux 或仅运行几分钟便被锁定。由于症状非常明显，所以容易诊断出这种不良状态下的 CPU 是有缺陷的。但更多的是一些不易检测到的细微的 CPU 缺陷；一般情况下，不太明显的错误能引起机器无明显原因的不时锁定，或导致某些进程意外死掉。多数 CPU 不稳定问题可通过“训练”CPU 来触发 -- 给 CPU 分配大量的工作，促使其变热，可能还会死机。让我们看一下压力测试 CPU 的一些方法。
当听说测试 CPU 稳定性的最好方法之一是 Linux 内建的 -- 内核编译，您可能会感到奇怪。gcc 编译器是测试一般 CPU 稳定性的一个很好的工具，内核构建使用整个 gcc。通过在 /usr/src/linux 目录创建并运行下面的脚本可以对您的机器进行 industrial-strength 内核编译压力测试：
cpubuild 脚本
#!/bin/bashmake depwhile [ "foo" = "foo" ]do make clean make -j2 bzImage if [ $? -ne 0 ] then echo OUCH OUCH OUCH OUCH exit 1 fidone
您将注意到此脚本 重复编译内核。原因很简单 -- 一些 CPU 有断断续续的故障，使得它们在 95% 的时间里顺利地编译内核，但又不时地使内核编译爆炸。通常情况下，这是因为在处理器加热到一定温度（在该温度下处理器变得不稳定）之前可能进行了 5 个或更多内核编译。
在上面的脚本中，确保 -j 选项进行调整，使紧跟它的数字大于系统中 CPU 的数目；换句话说，单处理器使用 "2"，双处理器使用 "3"，依此类推。-j 选项表明平行构建内核，确保在编译每个源文件后总有至少一个 gcc 进程准备就绪 -- 确保 CPU 承受的压力达到最大。如果下午不准备使用 Linux 机器，请继续运行此脚本并让机器重新编译内核几个小时。
可能的 CPU 问题
如果脚本持续几个小时运行顺利，祝贺您！您的 CPU 已经通过了第一个测试。但是，上述脚本可能会意外死掉。如何知道是 CPU 有问题而不是其它的问题呢？如果 gcc 发出与下面类似的错误，则很有可能是 CPU 有问题：
gcc: Internal compiler error: program cc1 got fatal signal 11[/pre]
这时，CPU 有三种可能的状态：
如果您输入 "make bzImage" 重新进行内核编译，并且编译器死在同一文件上，请继续一遍遍输入 "make bzImage"。如果试了大约十次之后，构建进程继续死在此特定文件上，那么问题很可能是由（很少）gcc 编译器错误引起的，该错误是由此特定的源文件而不是有问题的 CPU 触发的。但是，这些天 gcc 很稳定，那么这种情况发生的可能性很小。
如果您输入 "make bzImage" 重新进行内核编译，并且稍后得到另一个信号 11，那么您的 CPU 很可能快要无法使用了。
如果您输入 "make bzImage" 重新进行内核编译并且内核编译成功，那也不意味着您的 CPU 是好的。通常这意味着仅当 CPU 升到一定的温度以上（CPU 使用超过一定时间后会变热，可能会使几个内核编译达到此临界点），CPU 故障才不时地显露出来。
抢救 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 使用情况、主板温度设置和其它一些事情：
gkrellm 正在运行
还有其它与 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 程序，恢复正常操作。
