【51CTO精选译文】这篇教程的诞生过程实在相当纠结。很长时间以来我一直在考虑要不要写这么一篇东西，最主要的原因在于对硬件相关问题进行故障排查可能是计算机管理领域最棘手的工作。即使是经验相当丰富的用户有时也会遇上自己搞不定的状况，并在试图解决那些微妙、古怪、难以捉摸甚至无法确定的软硬件冲突困境时碰上钉子。想在网络上寻找答案？我们找到的很可能是上万个无关主题，最终在空荡荡的论坛上孤独徘徊、耗尽余生。
不过就个人来说，我自认为算是个自负的极客、对技术难题和写作手法都有相当的信心。今天我打算尽量与大家分享一些实用的技巧与处理方法，希望有助于读者朋友理解、查明并最终搞定硬件难题--无论您使用的是Linux设备还是其它什么平台。这篇教程无法保证100%有效，其中的某些方法也可能不太容易掌握，但它还是能起到一些作用。请大家随我一起探寻硬件故障中的奥秘吧。
硬件故障类型
在开始着手诊断硬件问题之前，我们首先需要调整预期、充分了解工作中可能遇到的硬件故障类型，这一点非常重要。最后，大家还必须掌握硬件故障的实际表现形式。
硬件无法工作
最常见的故障源自电子设备中的某一部分发生损坏，但例外情况同样时有发生。如果大家的电源出了问题，设备当然没办法启动，这个道理非常简单。除此之外，显卡、声卡甚至记忆棒都可能在关键时刻挂掉，并带来各种各样的奇怪表现。在这种情况下，系统也许仍能通过BIOS自检并进入操作系统，甚至允许用户进行一定程度的正常操作。而在某些情况下，我们可能会直接感受到设备故障，例如屏幕分辨率突然变得非常低--这肯定是因为显卡驱动程序无法正常工作；或者听音乐时没有声音，那就是声卡的问题。在某些情况下，操作系统还可能直接弹出错误提示信息。
硬件的不稳定性故障
不稳定性是我们面临的最困难、也最不容易确诊的故障类型之一。如果大家的硬件仅有某一部分发生损坏，那么整体设备也许仍能正常运转，只在特定情况下偶尔出现问题。这往往令用户摸不着头脑，无法把异常状况与对应设备联系到一起，从而得出正确结论。另外，即使是同一故障也可能存在多种表现形式，它们彼此之间看似毫无关联，但足以把用户折磨得死去活来。
某些类型的错误甚至不会影响设备的正常功能，但它们却有可能偷偷导致数据损坏或设备整体性能下降。这类问题相当阴险，因为我们往往习惯于将其归罪于操作系统损坏或软件冲突。举例来说，如果我们的记忆棒中存在少数损坏单元，使大家在访问并使用这些存储空间时发生段错误，各位打算怎么办？再有，我们可能会把系统内核崩溃与某些软件挂上钩，但其真正根源或许在于内存故障或总线错误，您想到了吗？另一个很好的例子就是三年前我在自己老款T61设备上遭遇的无线/笔记本问题。我专门用来玩游戏的发烧级台式机还碰到过由地线引发的故障。
固件/驱动程序故障
驱动程序故障常常表现得像是硬件出了问题，但不同之处在于其发作状况比较稳定、不像硬件那样时好时坏。通常情况下，软件问题导致的状况比较一致且能够再现。在某些情况下，我们的驱动程序甚至无法与硬件进行通信；而在另一些情况下，存在bug的驱动程序会令设备以意料之外的方式运作。有时候这类问题还会转化成全局功能缺失，例如内核崩溃、黑屏、白屏以及其它各种奇怪的故障。
其它注意事项
大家还必须意识到，某些系统可能会锁定BIOS以防止我们使用某些硬件组件或功能，或者是出于某种目的而禁用这些组件。在后面的文章中我们将进一步讨论BIOS的相关话题。
最后，大家可能会在无意中将那些设计上存在冲突的硬件组件放在一起工作。某些供应商生产的硬件也许只针对某款特定操作系统，因此我们无法从官方得到任何其它系统平台上的驱动程序支持。不过有些硬件能够与其它产品使用同样的公版驱动程序，例如Lexmark打印机就能完美接纳PCL驱动程序。#p#
硬件分析
由于在追踪硬件问题、尝试加以解决方面存在数以百计的处理方案，因此在实际操作中感到迷茫或是淹没在互联网那数不清的案例当中都是极为正常的现象--人生最大的悲哀也莫过于此。我给大家的忠告是，尽管以有条理的方式对待每一次硬件故障，最大程度减少误判与干扰因素。
好吧，我们先来假设大家已经遇上了一起硬件故障。在现实中有些故障真实存在、有些则只是我们的误判或者偶然现象，不过在这里我们暂时只讨论那些真正存在的问题。
备份与更新
首先也是最关键的一步，为自己的数据做好备份。一旦设备开始捣乱，我们的底线就是千万不要失去任何宝贵的资料信息，这一步在修复计划中可谓不可或缺。
第二个步骤是对设备进行全面更新。在Linux领域，这意味着下载所有可用的系统更新，因为其中可能包含着对解决硬件问题至关重要的固件及驱动程序修复补丁。就算没有这些针对性内容，新内核也往往能更好地支持设备上的硬件。举例来说，SSD TRIM命令只能在2.6.33内核中生效。同样，Sandy Bridge也仅支持最新的几个系统发行版本。英伟达的290.XX驱动程序中可能包含一些早先版本不具备的额外功能或重要修复代码。
启动日志
如果我们的设备中存在已经完全损坏、部分损坏或者发生严重问题的硬件，那么首先想到的肯定是要看看启动过程有没有对此进行记录及反馈。为此，大家需要查询系统中的启动日志。在大多数情况下，Linux系统的启动日志被保存在/var/log路径下，文件名通常为boot.log或者boot.msg等。如下图所示：
不要看到错误信息就关注！
从上图中，大家可以看到几条红色的失败提示信息与黄色警告信息。暂时把它们放在一边，它们可能与故障有关也可能并无关系，事实上我们不要因为干扰因素而影响到正常的检查流程。再次强调，大家现在要做的是确定硬件方面的某种问题，就目前而言，我们只应该关注那些与问题硬件确切相关的内容。如果没什么关系，那么直接跳过就好。事实上，很多情况下我们都可以预估问题的出现范围并直接到对应部分进行检查。#p#
Dmesg命令
另外一些颇具价值的信息被保存在内核缓冲区日志当中，我们通常可以利用dmesg命令来调用。当然，有时候该日志也会被保存在/var/log路径下的同名文件中。这条命令会显示所有缓冲区内的内核信息，其中一些也同时存在于标准系统日志当中--即由syslog生成的/var/log/messages。
除此之外，dmesg还会显示大量硬件初始化信息，我们可以借此摸索可能出现的问题或冲突。同样，这部分信息中不正常的内容也会很多，一一阅读并理解会浪费大量时间，所以请有针对性地进行处理。大家最应该关注的是模块名称与硬件地址，它们是由冒号隔开的数字与字母构成的字符串。
在下面的例子中，我们可以看到英伟达模块的初始化情况。由于模块不支持GPL，因此导致系统内核受损--另外，声卡的初始化信息也能在下图中找到。
Lsmod命令
我们之前在许多场合都使用过lsmod命令，这条命令能够被加载到系统内核中的模块名称及其使用次数。在进一步分析处理之前，大家应该首先确定设备拥有基本驱动程序支持。举例来说，如果我们想了解为什么英伟达显卡无法工作，那么首先得弄清驱动程序是否被正确载入或者说没有出现冲突。虽然对于普通用户来说，判断驱动程序未被载入的原因似乎有些困难，但至少我们已经了解到导致问题的根源，这也算是个了不起的成果。
/sys/devices
现在我们再来看看更实用的检查方法。将启动信息与dmesg结合起来虽然能为我们提供一些基本信息，但这些信息却并不十分可靠。在无法断定信息真伪的情况下，大家需要直接审查内核架构并检测载入的驱动程序。
在Linux系统中，由于架构的单一特性，组件会直接通过编译进入内核或作为可动态加载的模块。与硬件之间相互通信的模块就被称为驱动程序。无论是直接进入内核还是成为可加载模块，组件最终都会出于某种目的而驻留在内核中。这是一种抽象软件层，用户无法直接进行控制。
然而，以间接方式进行部分控制还是可以的，我们能够利用伪文件系统/proc及/sys渗透到一部分内核架构中去。大家可以通过修改看似普通的文件来实时变更内核架构，这将改变系统的运作方式。/sys文件系统则允许用户对硬件以及内核模块进行修改。
现在，如果大家还记得之前图片中列出的数字，我们已经可以让它们派上些大用场。浏览/sys/devices下的子目录并检查哪些硬件组件已经连入注册接口。
某些模块拥有可写入参数，我们能够凭借root权限对其加以修改、进而改变硬件的运作方式。举例来说，我的LG笔记本的PCI插槽上接有USB5设备，它正好拥有可写入参数。如果大家在这个文件中填写不同数值，就能够启动或关闭对特定USB接口的访问。
在实践中，大家会发现浏览/sys绝对是个对经验与知识要求很高的细致活，这点在尝试解决硬件问题时尤为明显。普通用户对不同参数及值的理解更是有所欠缺，但这都不要紧，我想强调的只有一点：/sys目录能够提供很多有用的信息。#p#
Lspci命令
要想对所有接入的硬件组件及其对应驱动程序进行扫描，这里还有一种更简单的方法。系统命令lspci能列出所有接入PCI总线的设备，不过就连遗留硬件也会被显示出来。
现在的问题是，lspci到底是从哪获得这些信息的？好吧，如果大家真想知道，那么我们一起把lspci与strace搭配起来看看。毫无疑问，lspci是对/sys目录进行扫描以获取接入设备信息的，其中包括连接端口、供应商ID、设备类型以及配置等。
最后，lspci会参考/usr/share/hwdata/pci.ids文件中所包含的硬件供应商静态列表。该列表会将供应商ID数字转译成自然语言名称，方便我们直接读取lspci所输出的扫描结果。
某些Linux发行版还会为lspci命令配备图形化前端，这样我们就能像在Windows平台上那样从窗口中读取系统信息了。但需要提醒大家的是，命令输出查询起来更方便，尤其是在进行调试工作时。
/var/log/messages
最后但同样重要的是，我们还可以通过查询系统日志得到想要的答案。再次强调，将注意力集中在出现问题的硬件身上，别被无关紧要的错误所引导。作为演示，我们向设备插入U盘并查看系统会向我们反馈哪些信息。要实时进行信息查询，我们要用到tail命令。
要注意系统列出的内容。在这个实例中，我们会看到系统正确识别到了新接入的驱动器。但这并不意味着我们可以直接开始使用，大家一定已经发现，系统没有自动为其安装驱动程序、我们目前也没有足够的使用权限等等。甚至U盘本身也可能存在故障。但无论如何，设备已经被系统内容正确识别了，所以我们可以排除这方面的可能性了。
#p#
实例汇总
有了前面提到的知识基础，现在我们该处理一些实例，在操作中学习并理解。当前我怀疑自己的英伟达显卡在Ubuntu中存在硬件/驱动程序间的冲突，因为虽然系统提示驱动已激活但设备仍无法正常工作。
在某些情况下，我无法使用自己的硬件--无线网卡--更确切地说，相关固件由于许可及识别冲突等原因而不存在于内核当中。Debian与Trisquel两套发行版都有这样的问题。
其它事项
如果，我的意思是只有用尽了上述所有方案都搞不定问题时，大家才应该到互联网上搜索并追寻自己想要的答案。虽然我已经提到，本文所介绍的各类工具不一定总能帮你找到问题的根源，但它们一般来说都很有效，所以推荐大家优先从这里入手。
现在大家应该从网上搜索资源并与眼前的问题进行比对。在大多数情况下，我们只走马观花看几眼就能剔除掉很多没用的信息。如果有人面临与您相同的故障症状，但导致问题的硬件却完全不同，别犹豫--马上离开。如果有人面临同样的症状，但使用的操作系统不同--马上离开。虽然已经说过很多次，但我还是要强调，别为没意义的事情分神。有时候多种故障可能会归结为同一个内核错误，毕竟内核能够输出的信息是有限的。可以肯定的是，许许多多不同各类的问题都会引发相似的故障表现。
这里我向大家推荐一些寻找答案成功率较高的网络资源：Phoronix，虽然只是个论坛，但经常会组织检查及基准测试活动；Linux drivers 是个很实用的编译类门户网站；再就是linuxquestions.org网站，这里的资源非常不错，值得大家多逛逛。
#p#
最后，BIOS
检测流程当然由大家自己说了算。不过如果所有尝试都宣告失败，那么更新BIOS恐怕是我们惟一的出路。一般情况下，整个更新过程应该是很安全的，但一旦出现问题，那就绝不会是小问题--你的设备很可能直接变砖。这也正是我将BIOS更新作为最后一节内容的主要原因。另外，在碰BIOS之前请务必确保大家已经尝试过前面提到的所有处理方法，例如利用其它系统发行版检测硬件兼容性。
BIOS内容的改动可能启动或禁用某些功能，例如火线、蓝牙、RAID控制器及其它组件，这将直接影响操作系统的运作以及识别并调用某些硬件的能力。
总结
Linux硬件故障排查工作要求我们具备相当的知识并熟悉命令行与系统信息。另外，灵活的处理方案与实用信息在某些特定操作系统中可能无法生效。修改内核空间的能力可以帮助大家诊断并解决与硬件有关的技术问题。
在今天的文章中，我们共同探讨了如何有条不紊地利用各类工具及实用程序解决Linux系统中的硬件故障。大家了解到故障的具体类别、如何咨询系统日志以及如何使用lspci及lsmod等命令。最重要的是，我们还与BIOS、驱动程序及系统调试进行了一番浅层次但意义深远的接触。希望这篇文章能帮助大家从容应对未来道路上的问题。不过请大家别忘记，有时候就算使尽浑身解数也无法搞定难题，这很正常、并不丢人。硬件本身发生了损坏，这就不是我们所能挽回的局面了--所以请保持轻松愉快的心情。
就写到这里，感谢收看。
原文链接：http://www.dedoimedo.com/computers/linux-hardware-troubleshooting.html
