Kode Vicious - @kode_vicious
PDF亲爱的KV，
调试故障硬件的正确方法是什么？
深陷Bug之中
亲爱的深陷Bug之中，
我建议拿一把非常锋利的刀，随机切割电路板上的走线，直到它能工作，或者闻起来很奇怪！ 我猜你不是在问导致我在另一篇文章（《持久性与变革》，通讯，2008年12月）中使用“changeineer”这个词的那个问题。 我认为你有一块真正故障的硬件，并且你已经将之前的三个版本退回给制造商，还附上了措辞严厉的信件，其中隐晦地提及如果他们继续给你发送损坏的产品，将采取法律行动。
硬件问题可能和竞争条件（以后再讨论）一样，是最难解决的事情。 虽然硬件工程师可能会嘲笑使用螺丝刀的软件工程师，但如果你想让他们真正害怕，就拿出逻辑分析仪或示波器，并将其连接到他们的电路板上。 可悲的是，大多数软件工程师都没有接受过使用逻辑分析仪的培训——甚至没有接受过基本的电气工程培训——因此你只能满足于通过电路板供应商或操作系统供应商提供的任何软件来摆弄电路板。
信不信由你——我确信如果你是一名典型的软件工程师，你不会想听到这个——最好的起点是硬件供应商的文档。 当然，许多硬件供应商对文档的看法和软件供应商一样糟糕。 我见过的文档质量参差不齐，从无法使用的糟糕到“让人想撞墙哭泣”都有。 我很少见到既正确又具有结构化的硬件文档，而且这种结构对于最初编写文档的人以外的任何人来说都有意义。 令人欣慰的是，现在很少有可能通过将错误的值放入错误的内存位置来完全摧毁一块硬件；像最初的《星际迷航》中那样的爆炸式计算机时代在未来几个世纪内仍然不会到来。
话虽如此，但通过软件导致硬件损坏绝对是可能的，或者更常见的是，通过触发设备中一些看似无关的配置魔法来掩盖你遇到的任何问题。 并不是KV反对魔法；只是他倾向于完全不信任它……
如果你幸运的话，你会有系统文档，或者可以让你的律师发送一份保密协议和一封信给供应商，以获得他们愿意给你的任何东西。
首先阅读文档。真的，相信我。 它最终可能完全没用，但如果你在文档中找到正确的少量信息，它也可能会为你节省大量时间。 我倾向于通读所有可用的寄存器和配置选项（通常有数百个），并标记我认为可能与我的错误相关的那些。 然后我逐个调整它们，直到得到结果。 虽然这是一个繁琐的过程，但它是我见过的效果最好的方法。
通常，除了已经发生故障的设备驱动程序之外，你没有其他好的方法与硬件交互。 随着设备变得越来越复杂，供应商发布了测试和配置程序，这些程序可以用来直接与设备通信——例如，通过PCI总线。 如果你的硬件有这样的程序，并且它能工作，那么你真是太幸运了。 另一方面，如果它没有附带这样的程序，那么你可以使用一套工具来调试基于PCI的设备，即PCI Utilities，这在随附的侧边栏中进行了描述。
PCI Utilities已被移植到多个操作系统，Windows中可能存在类似的东西，但幸运的是，我没有遭受过这种痛苦。
如果这些方法都没有产生结果，而你仍然必须“让这东西工作起来”，那么，唉，是时候寻求帮助了。 你能从供应商那里获得的帮助质量似乎与设备的价格成线性相关。 廉价设备通常来自低成本生产商，他们没有资金聘请高质量的工程师来帮助解决问题，而昂贵的设备更有可能（但绝非保证）由拥有经验丰富的工程师的公司生产。 如果你要在工作中为一个项目指定设备，请选择来自看起来拥有更好工程师的公司的设备。 所有设备都有问题，但得到解决的那些问题背后都有良好的工程资源。 归根结底，便宜货就是便宜货。
一旦你联系到现场或客户支持工程师，你需要对他们友善。 我知道，你可能在想，“Kode Vicious怎么了？”，但这是真的。 对着人尖叫并告诉他们是白痴，因为他们没有考虑到你的个人极端情况，这不是快速修复错误的方法，即使你在一家大公司工作，并且你的CEO每天都打电话给他们的CEO要求修复。 你至少需要在你的bug存在的期间与这个人或这些人合作，所以礼貌和专业地与他们打交道非常重要。 回去再读一遍——我等你。
最后，你需要对问题做好记录。 没有什么比一份bug报告更令人沮丧的了，报告上写着“它坏了”——别笑，我见过不止一份bug报告几乎就是这么说的。 你需要能够说明它是如何坏的，什么时候坏的，是否一直坏，如何使其进入损坏状态，以及任何其他看起来与你看到的bug相关的信息。 你不应该只记录bug，还要记录修复。 当你与供应商的工程师合作时，你需要跟踪他们给你的补丁（如果有的话），硬件或驱动程序中的版本更改，关于可能出现的问题的各种理论以及这些理论是否成立，以及几乎所有其他与修复或解决bug相关的事情。 在这一点上，你通常既是bug修复的项目经理，又是供应商工程师的远程助手。 虽然这可能不是你认为你签约要做的事情，但它通常是解决硬件问题的一部分。
我希望你足够幸运，能从你的供应商那里获得不错的文档和支持。 如果不是，那么酒吧见。 我就是坐在最远端，一边哭一边对着芯片手册喝着永远满杯的杜松子酒和奎宁水的那个人。 我的酒保很了解我。
KV
KODE VICIOUS，凡人称之为George V. Neville-Neil，为乐趣和利润从事网络和操作系统代码方面的工作。 他还教授与编程相关的各种主题的课程。 他感兴趣的领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。 他获得了马萨诸塞州波士顿东北大学计算机科学学士学位，并且是、Usenix协会和IEEE的成员。 他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。
PCI Utilities
PCI Utilities软件包包含各种处理PCI总线的实用程序，以及一个用于便携式访问PCI配置寄存器的库。 它包括lspci，用于列出所有PCI设备（对于调试内核和设备驱动程序非常有用）和setpci，用于手动配置PCI设备 (http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml)。
最初发表于Queue第6卷，第7期——
在数字图书馆中评论本文
更多相关文章
Charisma Chan，Beth Cooper - 调试Google分布式系统中的事件
本文介绍了2019年关于谷歌工程师如何调试生产问题的研究成果，包括工程师以不同组合有效调试所使用的工具类型、高级策略和低级任务。 它考察了用于捕获数据的研究方法，总结了生产调查的常见工程过程，并分享了专家如何调试复杂分布式系统的示例。 最后，本文扩展了这项研究的谷歌具体细节，以提供一些你可以在你的组织中应用的实用策略。
Devon H. O'Dell - 调试心态
软件开发人员花费35-50%的时间来验证和调试软件。 据估计，调试、测试和验证的成本占软件开发项目总预算的50-75%，每年超过1000亿美元。 虽然工具、语言和环境减少了个人调试任务所花费的时间，但它们并没有显着减少调试的总时间，也没有减少这样做的成本。 因此，过度关注开发过程中消除bug是适得其反的；程序员应该将调试视为解决问题的练习。
Peter Phillips - 使用跟踪增强调试
创建模拟器来运行旧程序是一项艰巨的任务。 你需要透彻理解目标硬件以及模拟器要执行的原始程序的正确功能。 除了功能正确之外，模拟器还必须达到以原始实时速度运行程序的性能目标。 实现这些目标不可避免地需要大量的调试。 这些错误通常是模拟器本身中的细微错误，但也可能是对目标硬件的误解或原始程序中实际已知的错误。 （原始程序的二进制数据也可能已被微妙地损坏或不是预期的版本。）
Queue读者 - 又一天，又一个Bug
作为本期关于程序员工具的一部分，我们在Queue决定就调试主题进行一次非正式的网络调查。 我们请你告诉我们你使用的工具以及你如何使用它们。 我们还收集了关于那些难以追踪的bug的故事，这些bug有时会让我们想到从事其他职业。
© 保留所有权利。