(转载） Linux 硬件稳定性指南

Kinwa

http://www-900.ibm.com/developer ... y/part1/index.shtml
http://www-900.ibm.com/developer ... y/part2/index.shtml
Linux 硬件稳定性指南，第 1 部分                        
       
       
教程：编译 Linux 内核
CPU 和内存疑难问题解答

Daniel Robbins (drobbins@gentoo.org)
总裁／CEO，Gentoo Technologies, Inc.
2001 年 3 月

    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/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 的数目；换句话说，单处理器使用 "2"，双处理器使用 "3"，依此类推。-j 选项表明平行构建内核，确保在编译每个源文件后总有至少一个 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

主要的内存突发问题（比如“死亡”位）将在几秒钟内检测出来。由特定位模式触发的故障（不幸的是这种故障相当普遍）可能几个小时也无法检测出来，但最终应该会检测出来。memtest86 一检测到缺陷位，就将在屏幕底部显示一条消息 -- 测试将继续。当早上打开监视器时，您会发现测试已完成，如果在屏幕上看不到任何警告信息，那么 RAM 确定是好的。但是，如果您继续遇到“坏内存症状”部分列出的问题，那么您的 RAM 可能有突发性问题（这种问题很少发生），可能仍需换掉此 RAM。

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

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

现在需要做的只有这些；在本系列的第 2 部分和最后部分中，我们将讨论如何修复与硬件配置有关的问题，包括 IRQ 和 PCI 的潜在问题。同时，您可能想要查看下列参考资料。

参考资料

    * 请下载 lm_sensors 软件包。
    * 请选择一个 gkrellm 副本。
    * 获取 cpuburn 程序。
    * 获取自己的 memtest86 副本。
    * 如想获得关于 "signal 11 problem" 的更多信息，请查看 Sig 11 常见问题解答。
    * 在 Linuxpowered.com 的 Window-maker 链接页上，您会发现很多 Window-maker dockapps（其中一些是图形 CPU 和传感器数据）。
    * 如果您正在尝试诊断与 nVidia 图形卡相关的硬件问题，请务必查看 GeForce 常见问题解答。那里有许多与 Linux 和 Windows 有关的信息。
    * 关于另外的加速 nVidia 驱动程序的疑难问题解答信息，请查看我发送到 gentoo.org 站点的 Christian Zander 的 nVidia 疑难问题解答指南。使用 IRC 并连接到 irc.openprojects.net 可获取最新的版本。加入 #nvidia 频道，然后转到 "/msg ice-dcc xdcc list" 可接收到您请求自动 dcc 下载的一列文件。
    * 还可以在 developerWorks 上参阅教程“编译 Linux 内核”和文章 “接触 2.4 Linux 内核，第 2 部分”。
        Linux 硬件稳定性指南，第 2 部分                 Daniel Robbins (drobbins@gentoo.org)
总裁兼 CEO，Gentoo Technologies, Inc.
2001 年 7 月

    Linux 之所以声誉卓著是它拥有非凡的稳定性。但如果硬件有缺陷或配置不当，即便是世界上最稳定的操作系统，也不能发挥其优越之处。在本文中，Daniel Robbins 分享他在让 NVIDIA TNT 图形卡使用 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 购买了一个迷你集成的散热片／风扇。

所以，在我收到 Video Cool 后，将显示卡上的 OEM 散热片去掉（造成质保无效），清洁 TNT 芯片，然后将 Video Cool 固定在芯片上。结果呢？显示卡不烫了，但死锁仍然存在。我从这段特殊的经历所吸取的教训是－如果一开始就确定系统冷却充足，那么根本不必担心由于不充足冷却引起的元件故障。这本身就是要投入时间和精力来确保工作站和服务器凉爽运行的极佳理由。既然已经考虑了发热问题，我知道死锁问题不太可能由异常的硬件引起，并且开始查看其它地方。

新驱动程序 －以及可能的解决方案？
我对 NVIDIA 驱动程序本身是否是问题所在，有点半信半疑。幸运的是，新版本的驱动程序刚刚发布，所以我立即升级，希望它能解决稳定性问题。遗憾的是，它没有，在 openprojects.net 上的 #nvidia 频道，我与其他人讨论之后，发现不是每个人都能够使驱动程序稳定运行，然而，对于许多人，它是稳定运行的。

在 #nvidia 上，有人建议我确保 V550 没有与另一块卡共用一个 IRQ。与标准的 XFree86 驱动程序不同，加速 NVIDIA 驱动程序需要一个 IRQ 来正常运行。要查看它是否有自己的专用 IRQ，输入 "cat /proc/interrupts"，您瞧，V550 与 IDE 控制器共用一个中断。在我解释这个问题之前，先讲述一点有关 IRQ 的简要背景。

PC 通常使用 IRQ 以及硬件中断，来允许外设，如视频卡和磁盘控制器，用信号通知 CPU，它们准备处理数据。在 PCI 总线出现以前，机器中的每个设备都有自己专用的 IRQ，这一点是很重要的。如果您的机器仍然使用 ISA 外设，那么这仍然是一个事实 － 所有非 PCI 设备都应该有自己专用的 IRQ。

IRQ 与 PCI
然而，PCI 总线有点不同。在系统中，PCI 分配了四个 IRQ 可供 PCI/AGP 卡使用。通常，多个设备可以共享这些 IRQ。（如果是这种情况，要确保共享 IRQ 的所有设备是 PCI 和 AGP。）尤其对于在可能有五个 PCI 和一个 AGP 插槽的现代机器，共享 IRQ 技术是非常重要的。没有共享 IRQ 技术，系统中使用 IRQ 的卡不可能超过四个。

但是，PCI IRQ 共享有一些限制。现代主板的 BIOS 和 Linux 内核通常支持 PCI IRQ 共享技术，但也有某些 PCI 卡在与另一个设备共享 IRQ 时，会直接拒绝正常工作。如果遇到系统随机死锁，特别是死锁发生与使用某个特定的硬件设备相关时，不妨尝试让 PCI 设备使用自己的 IRQ。第一步是查看系统中是否有任何设备共享 IRQ。可以遵循以下步骤来做到：

   1. 使用系统中的各种设备，如，磁盘、声卡、显示卡、SCSI 卡等等。这确保 Linux 会处理这些设备的中断。
   2. 用 "cat /proc/interrupts" 命令，会显示 Linux 内核到目前为止处理的所有中断的列表及其数目。查看该列表的最右栏。如果同一行中列有两个或更多设备，那么这些设备共享那个特定的 IRQ。

如果遇到有问题的设备是非 PCI 设备（ISA 或其它旧卡），那么您会发现 IRQ 冲突，可以尝试通过 BIOS、isapnptools 包或者对外设进行物理跳线来解决。请注意，如果设备是集成在主板上，即使它不占用物理 PCI 插槽，它也是 PCI 设备。

如果有问题的所有设备是 PCI 或 AGP 设备，那么是否有问题取决于硬件。通过以下步骤使所有的 PCI/AGP 设备有自己的 IRQ：

   1. 进入系统 BIOS，禁用所有不用的外设（USB、并行端口等等）。这可以释放一些 IRQ, 让每个设备尽可能的分配它自己的唯一的 IRQ。
   2. 进入 BIOS 的 PnP 部分，确保 BIOS 被配置成“非 PnP”操作系统。选中 "Reset ESCD data" 选项。这会强制 BIOS 在下次重新引导系统时给所有硬件设备重新分配 IRQ。
   3. 重新引导 Linux，使用硬件，用 "cat /proc/interrupts" 命令查看结果。现在，希望所有设备都使用自己的 IRQ。

如果仍有两个受怀疑的设备共享 IRQ，那么还有两种额外选项。有些 BIOS 设置程序可以允许您将确定的某个 IRQ 分配给特定的 PCI 插槽。很少见这种 BIOS 设置程序，如果您有其中之一，可以使用这种功能来消除冲突。如果 BIOS 中没有这个选项（大多数情况下没有），那么还有一种方法可以确保解决这种问题－关机，关闭电源，从插座上拔掉电源，并等几分钟。然后，打开系统机箱， 将 PCI 卡换一个插槽。这种办法好象不常见，但绝对管用，特别是当系统中有多余的 PCI 插槽时，这种办法特别有用（但您要花一些时间来给每一块卡找正确的插槽。）

我使用了这个“PCI 调换诀窍”，能够使系统中的所有设备都使用唯一的 IRQ。差不多了。正如您所见，有两个 IDE 设备仍然共享一个 IRQ：


# cat /proc/interrupts
           CPU0
  0:   52063600          XT-PIC  timer
  1:     616810          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:      89084          XT-PIC  ide2, ide3
  7:    1515741          XT-PIC  eth0
  8:     155928          XT-PIC  rtc
  9: 1139761505          XT-PIC  nvidia
10:     164000          XT-PIC  Ensoniq AudioPCI
12:    4458823          XT-PIC  PS/2 Mouse
14:     664176          XT-PIC  ide0
15:      38661          XT-PIC  ide1
NMI:          0
ERR:          0                       

但这是正常的，因为 ide2 和 ide3 设备是集成在 Promise FastTrak IDE 卡的同一芯片上。

现在（几乎）所有设备都有唯一的 IRQ，我尝试加速驱动程序，并且……仍然在不到一个小时内经历了一次死锁。显然，共享的 PCI IRQ 根本不是问题所在。唉……得花些时间看看其它地方（再一次）。

解决一个问题，发现另一个
一段时间后，我发现禁用 AGP 可以使 NVIDIA 驱动程序运行正常，但有一点慢。尽管不想这样做，但目前驱动程序的版本允许关闭 AGP，这可以在 XF86Config 中简单地添加一行来实现。关闭 AGP，我将视频的内存带宽降低了 4x，但是相当慢的 3D 仍然比根本无硬件 3D 加速快很多。在禁用 AGP 后，终于有了一个稳定的系统！然而，这种临时解决方案又造成另一个问题。每当运行 3D OpenGL 动画，声音回放会变得极端扭曲并且断断续续。唷！

幸运的是，能够找到解决声音问题的方案。用 setpci 实用程序为 PCI 设备设置较理想的等待时间。过一会儿，我会向您演示具体的解决方案 －但首先介绍一些背景知识。

您可能知道，PCI 总线是共享资源 － 所有 PCI 卡通过总线轮流进行通信，通常情况下，一切都正常。但由于 PCI 总线是具有有限带宽（虽然通常情况下足够）的共享资源，某个 PCI 卡可能会对系统中的其它 PCI 卡产生负面影响。例如，如果 PCI 卡 A 正在通过总线发送数据，同时，PCI 卡 B 也想发送数据，这会发生什么情况？卡 A 是优雅地让出总线，还是继续进行数据传输 －如果这样，要多长时间？

PCI 等待时间计时器
回答这个问题与每个 PCI 设备的配置设置，PCI 总线等待时间计时器，密切相关。通常，Linux 驱动程序为系统中的每个 PCI 设备设置了合适的 PCI 总线等待时间计时器值，大多数情况缺省设置是足够的（如果不是最优），所有设备相处融洽，系统工作正常。PCI 总线等待时间计时器可以取 0~248 之间的值。如果某个设备的设置为 0，那么当另一个设备要传输数据时，它会立即释放总线。如果设备的设置为 248，那么在停止之前会持续使用总线较长时间，而另一个设备等待轮到。

如果所有设备都有相对较高的 PCI 总线等待时间计时器设置，并且有大量数据正在通过总线发送，那么 PCI 卡通常在取得总线控制权且开始发送数据前，会等待较长一段时间。然而，一旦取得总线控制权后，在将总线释放给其它设备之前，它们会通过总线突发传输大量数据。这正是高的 PCI 总线等待时间计时器设置不但增加了等待时间（通过总线发送数据时的延迟）而且也 增加了有效带宽的原因。由于每个设备可以不中断地通过总线突发地传输大量数据，所以可以更加有效地使用 PCI 总线，并且 PCI 设备可以传输更多的数据。

另一方面，如果所有 PCI 设备具有低的 PCI 总线等待时间设置，那么当另一块卡需要传输数据时，它们会很高兴地放弃总线。这导致相当低的数据传输等待时间，因而没有设备会长期控制总线，造成其它设备等待。所有这些的负面影响是当两个或多个 PCI 设备同时要使用总线时，低的 PCI 总线等待时间设置减少了有效的 PCI 总线带宽。这种现象的发生是由于突发的大量数据传输很少发生，而且总线控制权切换频繁，增加了开销。

大多数 Linux 分发版包含称为 pci-utils 的工具，该工具允许您查看和改变 PCI 设备的等待时间设置。要查看当前 PCI 设备的等待时间设置，请输入：


# lspci -v

输入该命令将显示所有 PCI 设备的非常详细的信息。每个设备的 PCI 等待时间设置在第 3 行上列出，正好在 IRQ 设置之前。

PCI 等待时间方法
这与扭曲声音的问题有什么联系？唔，扭曲的声音是由于缺省的 PCI 等待时间设置，当运行 3D 加速时，V550 控制了 PCI 总线。这就是原因。V550 是 AGP 2X 卡，当关闭 AGP（以增加稳定性）后，到主存的卡的带宽减少了 75%！现在，当 V550 试图通过较慢的 PCI 总线获取与原来同样数量的数据时，几乎 100% 占用 PCI 总线，这是造成声音设备有问题的原因。由于音频设备的数据缓冲区通常较小，需要及时地将音频数据发送给它们以避免缓冲区欠载运行，因而它们特别易受 PCI 等待时间问题的影响。使用当前设置，V550 使用如此之多的 PCI 带宽，以至于没有留给声卡足够带宽用来传输数据，所以缓冲区欠载运行造成声音扭曲。

对于这个问题有两种可能的解决方案。第一种也是最明显的方案，使用 setpci 命令减少 V550 的 PCI 等待时间。这使得能够迅速地共享 PCI 总线，其它设备以较短的等待时间就可以传输它们的数据。我使用 setpci 命令来尝试这种解决方案，它起作用了。然而，我不准备采用这种方法，因为我想 最大化已经受到影响的 3D 图形性能，而不是进一步降低其性能。

我决定尝试第二种方案，该方案较之第一种，性能有所提高。不是减少 V550 PCI 总线等待时间，而是将所有设备的 PCI 等待时间都提高到相对较高的值 － 176（通常设备的缺省值大约是 32，除了 V550 缺省设为 200 以上）。然后，将对易受等待时间影响的设备的 PCI 总线等待时间设置成最大值 － 248。正如我希望的，声卡通过总线以相对较大的数据块突发传送数据，从而解决了这个问题。同时，其它设备也可以传输大块的数据，数据恰好小到不独占总线，大到能有效地使用总线。因为可以解决声音问题，同时又增加了机器 PCI 总线的有效带宽，所以我非常满意这种解决方案。下面是实现该诀窍的系统启动脚本摘录：

#"open up" the PCI bus by allowing fairly long bursts for all devices, increasing performance
setpci -v -d *:* latency_timer=b0

#maximize latency timers for network and audio, allowing them to transmit
#more data per burst, preventing buffer over/underrun conditions

setpci -v -s 00:0f.0 latency_timer=ff
setpci -v -s 00:0e.0 latency_timer=ff  

在第一行，-d *:* 选项告诉 setpci 将这个设置应用到所有 PCI 设备。latency_timer=b0 选项将计时器设置为 176（"b0" 是 176 的十六进制表示。）。最后两行的 -s 选项指定按照 PCI 总线／插槽和功能而不是按厂商和设备 ID 来设 PCI 设备。也就是当您输入 lspci 命令时，列出的第一串数字。ff 值指定了等待时间计时器设置为 256，它会由 setpci 取整到 248。如果碰到相关 PCI 等待时间计时器相关问题，可以用 lspci 和 setpci 来尝试查找您系统的最优值。如果硬件能自己处理它，最好将计时器的值设置较大一些。

参考资料
这次故障排除对我来说，是一次很好的学习经验，我希望对您也是如此。现在，耐心地等待 NVIDIA 驱动程序（0.9-7）的下一个发行版。希望能解决 AGP相关的不稳定问题。下面是一些有关 NVIDIA 的优秀资源，也许您会感兴趣。

    * 请阅读 Daniel 本系列的上一篇 developerWorks 文章，Linux 硬件稳定性指南，第 1 部分，在这篇文章中，他向您演示了如何诊断和纠正 CPU 异常现象，以及如何测试 RAM 的缺陷。

    * 请查看 NVIDIA 的加速 Linux 驱动程序。

    * 如果您尝试诊断与 NVIDIA 图形卡相关的问题，请确保先查看 GeForce FAQ。那里有许多与 Linux 和 Windows 相关的信息。

    * 如果想要了解更多有关加速 NVIDIA 故障排除方面的信息，请查看 Christian Zander 的 NVIDIA Troubleshooting Guide，我已经将它放在 gentoo.org 网站上了。

    * 通过使用 IRC，然后连接到 irc.openprojects.net，可以获取故障排除指南和其它与 NVIDIA 相关文件的最新版本。欢迎加入 #nvidia 频道，然后使用 "/msg ice-dcc xdcc list" 来接收请求自动 dcc 下载的文件列表。这是求教的好地方，#nvidia 的人通常会很友好，而且愿意向您提供帮助。

    * 您也许想查看 Linux Powertweak 项目。Powertweak 可以让您使用 GTK 和基于控制台的界面来配置 PCI 等待时间计时器设置（还有其它一些设置）。

    * 请访问 PC 机电源和冷却设备，购买象小型的、散热片与风扇集成在一起的冷却设备以及 Video Cool。

    * 请查看 Tennmax 的 Lasagna 系列冷却器，根据我的经验，它的冷却能力要比 Video Cool 要高，但噪声要大些。

    * 请浏览 developerWorks 上更多 Linux 资源。

    * 请浏览 developerWorks 上 更多开放源码资源。

kilo

不错的文章

redspider

感谢，受益匪浅