级别: 初级 Daniel Robbins (drobbins@gentoo.org), 总裁兼 CEO
2001 年 7 月 01 日 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。可以遵循以下步骤来做到:
- 使用系统中的各种设备,如,磁盘、声卡、显示卡、SCSI
卡等等。这确保 Linux 会处理这些设备的中断。
- 用 "cat /proc/interrupts" 命令,会显示 Linux
内核到目前为止处理的所有中断的列表及其数目。查看该列表的最右栏。如果同一行中列有两个或更多设备,那么这些设备共享那个特定的
IRQ。
如果遇到有问题的设备是非 PCI 设备(ISA
或其它旧卡),那么您会发现 IRQ 冲突,可以尝试通过 BIOS、isapnptools
包或者对外设进行物理跳线来解决。请注意,如果设备是集成在主板上,即使它不占用物理
PCI 插槽,它也是 PCI 设备。
如果有问题的所有设备是 PCI 或 AGP
设备,那么是否有问题取决于硬件。通过以下步骤使所有的 PCI/AGP
设备有自己的 IRQ:
- 进入系统
BIOS,禁用所有不用的外设(USB、并行端口等等)。这可以释放一些 IRQ,
让每个设备尽可能的分配它自己的唯一的 IRQ。
- 进入 BIOS 的 PnP 部分,确保 BIOS 被配置成“非
PnP”操作系统。选中 "Reset ESCD data" 选项。这会强制 BIOS
在下次重新引导系统时给所有硬件设备重新分配 IRQ。
- 重新引导 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 设备的等待时间设置,请输入:
输入该命令将显示所有 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
的优秀资源,也许您会感兴趣。
- 您可以参阅本文在 developerWorks 全球站点上的
英文原文.
- 请阅读 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上
更多开放源码资源。
关于作者  | 
|  | Daniel Robbins
居住在美国新墨西哥州的阿尔布开克,他是 Gentoo Technologies, Inc.
的总裁兼 CEO、
Gentoo
Linux(用于 PC 的高级 Linux)的创始人,以及
Portage
系统(Linux 的下一代移植系统)的创始人。他是由 Macmillan
出版的几本书:
Caldera OpenLinux Unleashed、
SuSE Linux
Unleashed和
Samba Unleashed 的投稿人。Daniel
自小学二年级起就与计算机结下不解之缘,那时他首先接触的是 Logo
程序语言,并沉溺于 Pac-Man 游戏中。这也许就是他至今仍担任
SONY
Electronic Publishing/Psygnosis
的首席图形设计师的原因所在。Daniel 喜欢与妻子 Mary 和他们的女儿
Hadassah 一起共渡时光。可以通过
drobbins@gentoo.org 与 Daniel
联系。
|
对本文的评价
|