你碰到过的最难调试的 Bug 是什么样的？
我印象里面最难调试的两个bugs，都和硬件有关，但最终都可以通过BIOS来打补丁。 某著名公司还未上市的笔记本出了问题，在-10度的低温下经常莫名其妙死机。我作为BIOS专家，被千山万水召集到它的总部进行联合调试。在前台签署了一堆文档后，两个员工陪同我进入了一个大实验室。一进入实验室，画风突变，本来应该光洁明亮的房间，黑色的幕布从房顶垂下，将房间分割成十数个小间，像在进行敌特工作。在被引入需要工作的小间时，我要被气笑了。只见一根黑色的USB线从另一个小间连出，接在一台笔记本上。我被告知，只能在这台指定的笔记本上工作(我自己的不能用)，目标机因为机密，不能看，更不能碰！ 都说BIOS调试和看病一样，讲究望闻问切，但这种只在传说中给闺中小姐，悬丝诊脉的情景，却在这个号称高科技公司中演绎地活灵活现。我心中暗自盘算，该公司不是中国公司啊，为什么是个中医粉呢？看我面色不善，他们以为我受到了冒犯，解释道：“no offense, it applies to everyone, include us.”其实我是被该公司著名的保密文化震撼了。后来才知道，在幕布后面，机器上还套个假壳子，他们自己人也看不到真容。 闲话休提，开始工作，于是发生了以下有趣的对话： “死机死在哪了？” “死在操作系统里。” “你知道我不能看贵公司的操作系统源码，而我是个搞BIOS的吧！” “操作系统没有变，一定是BIOS出问题了！” 好吧，我又要被气笑了。硬件一定变了吧？操作系统能支持新硬件码？为什么总是BIOS背锅？！没办法，调试手段有限，只有硬看了。经过两天两夜的调试，通过重建调用栈，寄存器对比等发现，原因是连接CPU和PCH的DMI总线太长，比Intel推荐的要求长了一点点，相信是主板布线时受到些硬约束，硬件工程师觉得长一点点不碍事。就是这长的一点点，导致在低温下，信号完整性不佳，而出现错误，最终操作系统读取硬盘时报错。 解决的办法是BIOS先给DMI降频，继续验证。产品版不得不再做一次FAB，多一次验证。成本增加了，上市也延迟了一点。 某次主持开发一款E3主板。进度顺利，接近尾声。产品beta过后要进行压力测试，需要通过5000次soft reset，5000次hard reset，5000次Linux关机/启动，5000次Windows关机/启动，5000次UEFI Shell关机/启动。而在这个时候出了问题，在2000次左右关机/启动后，经常死在BIOS的内存初始化阶段，而且只有Windows/Linux会出现，重启和shell都是好的。 事关BIOS，我当然责无旁贷，组织了个攻坚团队，包括BIOS、硬件、操作系统、BMC和ME工程师。于是每天开会，每天跟踪进度，联合诊断。事情的难点在于每次关机/启动要3到5分钟，2000次需要3天多的时间。一次改正后，反馈周期太长。我不得不安排了6台机器进行迭代测试，安排不同部分的人分别盯守。 初步几天过后，分析下来是BIOS在读取spd信息时出错了。但为什么是关机/启动才出错？为什么开始不出错2000次后才出错？smbus读取代码十分简单，用过了很多代，为什么现在才出错？我仔细检查电路图，发现这代主板硬件工程师为了省事，将smbus的线都连在了一起，让BIOS、ME和BMC都可以访问内存信息，BIOS可以读取spd，ME和BMC可以读取内存温度，多方便！ smbus支持多host，硬件工程师这样做，也未尝不可。但ME、BMC和BIOS的祖传代码却缺乏相应支持，于是开会内容变成了各种争吵，事关谁该让一让的问题。最后决定大家都加上退避算法，解决总线冲突问题。 由于每次尝试都要等待好几天，加上牵扯方面太多，整个问题解决下来耗时一个多月，终于在产品发布之前，软件解决了问题。为此所有人出去大肆庆贺了一番。这个bug是我职业生涯中耗时最久的bug。 欢迎大家关注我的专栏和用微信扫描下方二维码加入微信公众号"UEFIBlog"，在那里有最新的文章。同时欢迎大家给本专栏和公众号投稿！