Linux:Linux系统中的硬件问题如何排查？

　　这篇教程的诞生过程实在相当纠结。很长时间以来我一直在考虑要不要写这么一篇东西，最主要的原因在于对硬件相关问题进行故障排查可能是计算机管理领域最棘手的工作。即使是经验相当丰富的用户有时也会遇上自己搞不定的状况，并在试图解决那些微妙、古怪、难以捉摸甚至无法确定的软硬件冲突困境时碰上钉子。想在网络上寻找答案？我们找到的很可能是上万个无关主题，最终在空荡荡的论坛上孤独徘徊、耗尽余生。

　　不过就个人来说，我自认为算是个自负的极客、对技术难题和写作手法都有相当的信心。今天我打算尽量与大家分享一些实用的技巧与处理方法，希望有助于读者朋友理解、查明并最终搞定硬件难题–无论您使用的是Linux设备还是其它什么平台。这篇教程无法保证100%有效，其中的某些方法也可能不太容易 掌握，但它还是能起到一些作用。请大家随我一起探寻硬件故障中的奥秘吧。

硬件故障类型

　　在开始着手诊断硬件问题之前，我们首先需要调整预期、充分了解工作中可能遇到的硬件故障类型，这一点非常重要。最后，大家还必须掌握硬件故障的实际表现形式。

硬件无法工作

　　最常见的故障源自电子设备中的某一部分发生损坏，但例外情况同样时有发生。如果大家的电源出了问题，设备当然没办法启动，这个道理非常简单。除此之外，显卡、声卡甚至记忆棒都可能在关键时刻挂掉，并带来各种各样的奇怪表现。在这种情况下，系统也许仍能通过BIOS自 检并进入操作系统，甚至允许用户进行一定程度的正常操作。而在某些情况下，我们可能会直接感受到设备故障，例如屏幕分辨率突然变得非常低–这肯定是因为 显卡驱动程序无法正常工作；或者听音乐时没有声音，那就是声卡的问题。在某些情况下，操作系统还可能直接弹出错误提示信息。

硬件的不稳定性故障

　　不稳定性是我们面临的最困难、也最不容易确诊的故障类型之一。如果大家的硬件仅有某一部分发生损坏，那么整体设备也许仍能正常运转，只在特定情况下 偶尔出现问题。这往往令用户摸不着头脑，无法把异常状况与对应设备联系到一起，从而得出正确结论。另外，即使是同一故障也可能存在多种表现形式，它们彼此 之间看似毫无关联，但足以把用户折磨得死去活来。

　　某些类型的错误甚至不会影响设备的正常功能，但它们却有可能偷偷导致数据损坏或设备整体性能下降。这类问题相当阴险，因为我们往往习惯于将其归罪于 操作系统损坏或软件冲突。举例来说，如果我们的记忆棒中存在少数损坏单元，使大家在访问并使用这些存储空间时发生段错误，各位打算怎么办？再有，我们可能 会把系统内核崩溃与某些软件挂上钩，但其真正根源或许在于内存故障或总线错误，您想到了吗？另一个很好的例子就是三年前我在自己老款T61设备上遭遇的无 线/笔记本问题。我专门用来玩游戏的发烧级台式机还碰到过由地线引发的故障。

固件/驱动程序故障

　　驱动程序故障常常表现得像是硬件出了问题，但不同之处在于其发作状况比较稳定、不像硬件那样时好时坏。通常情况下，软件问题导致的状况比较一致且能 够再现。在某些情况下，我们的驱动程序甚至无法与硬件进行通信；而在另一些情况下，存在bug的驱动程序会令设备以意料之外的方式运作。有时候这类问题还 会转化成全局功能缺失，例如内核崩溃、黑屏、白屏以及其它各种奇怪的故障。

其它注意事项

　　大家还必须意识到，某些系统可能会锁定BIOS以防止我们使用某些硬件组件或功能，或者是出于某种目的而禁用这些组件。在后面的文章中我们将进一步讨论BIOS的相关话题。

　　最后，大家可能会在无意中将那些设计上存在冲突的硬件组件放在一起工作。某些供应商生产的硬件也许只针对某款特定操作系统，因此我们无法从官方得到 任何其它系统平台上的驱动程序支持。不过有些硬件能够与其它产品使用同样的公版驱动程序，例如Lexmark打印机就能完美接纳PCL驱动程序。

硬件分析

　　由于在追踪硬件问题、尝试加以解决方面存在数以百计的处理方案，因此在实际操作中感到迷茫或是淹没在互联网那数不清的案例当中都是极为正常的现象–人生最大的悲哀也莫过于此。我给大家的忠告是，尽管以有条理的方式对待每一次硬件故障，最大程度减少误判与干扰因素。

　　好吧，我们先来假设大家已经遇上了一起硬件故障。在现实中有些故障真实存在、有些则只是我们的误判或者偶然现象，不过在这里我们暂时只讨论那些真正存在的问题。

备份与更新

　　首先也是最关键的一步，为自己的数据做好备份。一旦设备开始捣乱，我们的底线就是千万不要失去任何宝贵的资料信息，这一步在修复计划中可谓不可或缺。

　　第二个步骤是对设备进行全面更新。在Linux领域，这意味着下载所有可用的系统更新，因为其中可能包含着对解决硬件问题至关重要的固件及驱动程序 修复补丁。就算没有这些针对性内容，新内核也往往能更好地支持设备上的硬件。举例来说，SSD TRIM命令只能在2.6.33内核中生效。同样，Sandy Bridge也仅支持最新的几个系统发行版本。英伟达的290.XX驱动程序中可能包含一些早先版本不具备的额外功能或重要修复代码。

启动日志

　　如果我们的设备中存在已经完全损坏、部分损坏或者发生严重问题的硬件，那么首先想到的肯定是要看看启动过程有没有对此进行记录及反馈。为此，大家需 要查询系统中的启动日志。在大多数情况下，Linux系统的启动日志被保存在/var/log路径下，文件名通常为boot.log或者boot.msg 等。如下图所示：

　　不要看到错误信息就关注！

　　从上图中，大家可以看到几条红色的失败提示信息与黄色警告信息。暂时把它们放在一边，它们可能与故障有关也可能并无关系，事实上我们不要因为干扰因 素而影响到正常的检查流程。再次强调，大家现在要做的是确定硬件方面的某种问题，就目前而言，我们只应该关注那些与问题硬件确切相关的内容。如果没什么关 系，那么直接跳过就好。事实上，很多情况下我们都可以预估问题的出现范围并直接到对应部分进行检查。