Linux操作系统硬件稳定性指南.doc

Linux操作系统硬件稳定性指南（转载整合）CPU 和内存疑难问题解答Linux 负有盛名的特点之一是其非凡的稳定性。然而，如果您的硬件有缺陷或配置不正确，即使是世界上最稳定的操作系统也不会对您有什么帮助。本文中，Daniel Robbins 将告诉您如何诊断和修复 CPU 问题，并告诉您如何测试 RAM 缺陷。通过学习本文，您将学会确保您的 Linux 系统达到尽可能好的的稳定性。在 Linux 世界中，我们中的许多人已遭受过令人深恶痛绝的硬件问题之苦。许多人曾经配置了一台 Linux 机器、安装了最喜欢的分发软件、编译并安装了一些附加应用程序并且使各个部件都运行顺利，到最后发现新系统中有一个致命的硬件错误？无论是随机分段错误、数据毁坏、硬锁定、还是丢失数据其结果都是一样的 - 硬件故障使通常情况下可靠的 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/bash make dep while foo = foo do make clean make -j2 bzImage if $? -ne 0 then echo OUCH OUCH OUCH OUCH exit 1 fi done您将注意到此脚本重复编译内核。原因很简单 - 一些 CPU 有断断续续的小故障，使得它们在 95% 的时间里顺利地编译内核，但又不时地使内核编译崩溃。通常情况下，这是因为在处理器加热到一定温度（在该温度下处理器变得不稳定）之前可能进行了 5 个或更多内核编译。在上面的脚本中，注意调整 -j 选项，使紧跟它的数字等于系统中 CPU 的数目加 1；换句话说，若是单处理器使用 2，双处理器使用 3，依此类推。-j 选项告诉 make 程序行平行编译内核，确保在编译每个源文件后总有至少一个 gcc 进程准备就绪 - 确保 CPU 承受的压力达到最大。如果下午不准备使用 Linux 机器，请继续运行此脚本并让机器重新编译内核几个小时。可能的 CPU 问题如果脚本持续几个小时运行顺利，祝贺您！您的 CPU 已经通过了第一个测试。但是，上述脚本可能会意外死掉。如何知道是 CPU 有问题而不是其它的问题呢？如果 gcc 发出与下面类似的错误，则很有可能是 CPU 有问题： gcc: Internal compiler error: program cc1 got fatal signal 11这时，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 程序，恢复正常操作。内存测试拥有一个完全可靠的 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。轮番测试所有的模块后，您能够确定有缺陷的模块 - 不必将好的内存模块也扔到废物堆里。驱动程序、IRQ 与 PCI 等待时间Linux 之所以声誉卓著是它拥有非凡的稳定性。但如果硬件有缺陷或配置不当，即便是世界上最稳定的操作系统，也不能发挥其优越之处。在本文中，DanIEl Robbins 分享他在让NVIDIATNT 图形卡使用 NVIDIA 的加速驱动程序在 Linux 下工作方面的经历。如同他所做的那样，向您演示如何诊断以及解决 IRQ 和 PCI 等待时间计时器问题 可以使用这些技术，来确保系统不会经历死锁、不一致行为或数据丢失。不稳定性的诸多原因稳定性问题通常不是由有缺陷的硬件所引起的，但硬件配置不当或选择异常的驱动程序会造成这类问题。当我试图在 Linux 下让我的帝盟 Viper V550（一种基于 NVIDIA TNT 芯片的 AGP 图形卡）使用 NVIDIA 自己的加速驱动程序时，就开始了这方面的经历。NVIDIA 有它们自己的 Linux 显示驱动程序，它们是 NVIDIA、SGI 和 VA Linux 的合作结晶。与包括在 Xfree86 4.0 中的标准的仅 2D NVIDIA 驱动程序相比，这些驱动程序有许多优越之处。例如，它们有完全加速的 3D 支持。而且，这些驱动程序的特色是以 OpenGL 1.2 为实现，而不只是 Mesa 的增强版。所以，总而言之，若您有基于 NVIDIA 的图形卡，则这些加速驱动程序是您希望使用的，至少理论上如此。我让这些驱动程序正常工作的尝试，最终转变成一次极佳的学习经历，至少可以这么说。在安装完加速 Linux NVIDIA 驱动程序之后（请参阅本文后面的参考资料），启动 Xfree86，开始摆弄所有 3D 应用程序，现在，有应该有的出色加速。到那时为止，以前我必须重新引导到 Windows NT 才能利用 3D 加速。现在，虽然我不介意 NT，但必须重新引导才能使用 3D 应用，就有点让人恼火了，我非常高兴又少了一个要离开 Linux 而重新引导机器的原因。然而，在大约摆弄了一小时左右，我对于Linux 3D 渴望，经历了一次致命挫折 机器死锁了。鼠标完全一动不动，屏幕冻结，并且必须重新引导系统。是的，遇到了某种稳定性问题。但我无法确切知道是什么造成这一问题。是异常的硬件，还是图形卡配置不当呢？或者可能是驱动程序有问题 是它不喜欢基于 VIA KT133 芯片的 Athlon主板吗？无论什么问题，我希望尽快解决它。在本文中，我将分享如何解决硬件稳定性问题的过程。虽然，您所碰到的问题不一定与这完全相同，但我用来诊断和（大多数）解决问题的步骤在本质上是大同小异的，并且也可应用到许多不同类型的 Linux 硬件问题。首先，硬件我首先想到，可能是异常或需要冷却的硬件。一方面，帝盟 Viper V550 好象在 Windows NT 下没有问题。另一方面，可能是 Linux 使芯片有些过载，然后引起与发热相关的死锁。V550 确实极烫，它的 OEM 散热片似乎来不及散热。死锁和图形卡不够冷却的事实合在一起说服我转向 PC Power and Cooling（请参阅参考资料），为我的 V550 购买了一个迷你集