你碰到过的最难调的 Bug 是什么样的

白丁

你碰到过的最难调的 Bug 是什么样的 [复制链接]

实在忍不住了，第一次答题。

       08年的时候，我所在的公司调试三星的一款新的arm9 CPU，型号是S3C2416，是S3C2450的简配版。开发板刚入手的时候还是热乎的，因为三星的这个芯片刚刚出来，国内的代理商一共就几块开发板。各公司评估开发板都是分时使用的，只能预约几天。开发板入手的时候，三星那面连BSP都没有准备好，没有test code，没有u-boot，没有linux-kernel，甚至连Spec都是错误百出。还好我公司虽然小，研发能力在本地区还算不差，没有的东西可以自己移植。
       公司急着要出新品，在没有完全验证处理器的情况下，已经layout好了PCB，并且去打样了（当时竞争确实比较激烈，400M主频处理器而且这么低的价格绝对非常有诱惑力，所以公司决定冒这个险了）。在没黑没白的工作两周后，硬件和软件做的都差不多稳定了。这时候经理说，功能上问题不大了，我们来调一调休眠时的功耗吧（我们的产品一直以待机时极低功耗作为产品的卖点之一）。然而这却是噩梦的开始……
       公司的指标是待机时休眠电流500uA~800uA（电源电压4V）之间。以前所有的产品都在这个范围之内，三星方面的技术支持也明确表示，他们的解决方案达到这个指标。
       在我们调试过程中发现，整个系统休眠时的功耗在1800uA左右，一直降不下来。我们重新核对了所有的IO和外围电路的所有连接，以及IO口的电平配制，都没有问题。这时，我们决定测试每一个单元的功耗，用电流表分别串联进每一个外围电路，每个单元都很正常，就是系统总体偏大1000uA。
       我们连flash和ram的待机电流都测过了，仍然正常。好了，通过排除法已经确定了就是CPU的功耗过大。但是在开发板上调试休眠的时候，CPU功耗却是正常的。
       我们怀疑是开发板上CPU批号和我们自己拿到的CPU样品的批号之间有区别导致的，因为三星那面也在同步修正CPU的BUG，所以我们“大胆地”把开发板上的CPU用风枪吹下来，换到我们的PCB上，把我们的CPU贴到了开发板上进行交叉验证。结果是开发板仍然功耗正常，我们自己的板子上功耗偏大，还是大了1000uA。
CPU周边的核心电路设计出现了问题！这是我们一致的判断！但是问题出在哪里，我们反复核对开发板的原理图和我们自己板子的原理图，简直就是一模一样！因为整个核心电路这部分就是从开发板上抄过来的，实在没有什么可比对的。我们转而又去怀疑PCB的问题了。
       我是做系统移植和软件的，纯电气的问题我就无能为力了。闲着没事，我就反复检查我在linux中对系统休眠的IO引脚配置。然后挂着电流表做反复测试。电流表也对的起我，每次都是那个数。在一次系统待机的时候，我实在忍无可忍，一把抓起了板子。突然之间，电流表的读数飞快下降，降到了300uA！我松开手电流表的读数就又爬回来了。我把我这个惊奇的发现告诉了同事——一个硬件工程师。同事说可能是哪儿摸短路了，让我试试还能不能唤醒系统。我给了一个外部中断，系统神奇的正常唤醒了！
        “难道这就是问题？”，我想重现一下。但是再次在待机的时候抓起电路板的时候，读数并没有显著发生变化。“可能是手法不好”，我这么想着，用手在板子上继续抚摸着。果然！当我的手指按到PCB中的某一个位置时，电流又降了下来！反复试了几次，都是这样，就是在我手指按压的这一片，只要是用手指按着，电流就正常！
        这回同事开始重视了，打开PCB图，拿着电路图和万用表，查查我摸的到底是那块电路。硬件工程师觉得不可思议，因为我摸的部分并没有连接任何的电路——焊盘是空的。他于是用万用表的表笔去检查是不是PCB制版的问题，测一下这些空焊盘到底哪一个有电压。但是万用表中没有读数，这块都没有电。但是当万用表的表笔落在一处空焊盘的时候，电流表的读数又降下来了！
        这可是重大发现，我们对照了一下电路图。这处空焊盘是CPU中USB-Host模块的D+信号。由于我们的产品不需要USB的主机功能，所以这一块儿没有做任何处理。多亏了画原理图和PCB的同事，多留了一手，把USB Host的引脚都在PCB上做了个引出。谁也没想到是这个引脚出现了问题，辛亏这个信号引出来了，要是没有引出来，一辈子也查不出问题。我们给D+信号加了一个下拉电阻后，系统的功耗瞬间正常了。
        事后分析，三星自己开发板上有USB-Host的功能，所以USB-Host的外围电路也是完备的，所以功耗不会有问题。但是我们自己的产品上不使用USB-Host功能，没有相关外围电路，所以出了问题。这是因为在CPU休眠的时候，D+信号内部被悬空了！一句话，是三星CPU自己的BUG。我们修改了我们的PCB，增加了一个下拉电阻，同时将问题反馈给了三星。
         一个月后，当我们的产品量产时，三星也及时的解决了这个问题。那个下拉电阻也不需要再贴上去了。
最后用手指头找到了CPU的BUG，不知道这算不算是最难调的。
         反正这么多年了，这个经历留给我的印象是最深的。

白丁

也谈谈自己遇到的一个bug吧，我之前是做电商的，某较大的电商平台，突然有一天，C2C的店主反馈，看到的订单不是自己的，看到后台的商品列表也不是自己的

当时在睡午觉，看到这个问题，立马吓醒了，平时5个投诉就是一个故障单，那还都是一点体验上的小问题，这种订单混乱，商品混乱的错误，真是要紧急死了

于是，主管，总监都来看这个问题，一群大佬在后面看着，赶紧找最近几天的发布，测试情况，一个个回退，一个个检查，最后都无法解决问题，要知道时间一分一秒过去，半个小时还解决不了就要出大事了

后续又有用户来投诉，直接电话联系，远程控制电脑，发现操作起来巨慢，于是顺口问了一下用户的网络是什么网络。

结果他说是：“某城宽带”，一瞬间，有点感觉了，继续问其他几个投诉的客户都是“某城宽带”，然后我们打电话到那个宽带的运营商，得到的回复是“年底了，为了省流量，他们做了一部分缓存”

他们做了缓存
做了缓存
缓存
存

可是为毛TM的动态请求还做缓存啊，修改商品和订单的时候，随机返回成功或者失败 。。。。

＝＝＝＝＝＝＝＝＝回答下面的一些质疑＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
1.这个和时间戳也没关，我们都加了token的，他们也忽略了
2.你没猜错，他们把POST和GET动态请求也缓存了，就是说你提交了一个POST修改商品的请求，他从环缓存里面随便丢个回复给用户，用户感觉修改成功了，其实请求根本没到我们这边
是的，就是这么丧心病狂。

白丁

现象：
很简单，有段时间学校宿舍电信的网络，经常大面积集体掉线，时间不固定，但发现最常掉线的时间是晚上10点多，各种投诉抱怨，问候学校网管家人的。（心塞呀，学校其实真的维护设备的都是我们这帮兼职的学生，那帮老师就管收钱和发钱，工资那么低，累成汪还被骂。。。）

调试：
白 天去看了下机房设备硬件一切正常，当时以为是认证服务器配置太low，晚上上线人太多就卡死，导致心跳包中断，集体被下线，后来发现发现虽然到5000多 人后会有部分心跳包没回应，但是客户端允许部分掉包，人再多也不至于丢包到集体下线，最后查log发现这台机架上的所有交换机到那个时候都会重启一下，于 是重点关注。

机房是5号宿舍楼1楼的一间宿舍改造的，加了空调，另外从配电箱里接了不限电的电源（宿舍的电嘛，晚上会断电，还有功率限制），联通电信移动每家一个宿舍做机房，于是我在机房里蹲守。

第一晚是周六，一晚无事。

第二晚，到10点多一点，咔嚓一下机架上所有交换机的灯一下全灭了，过了几秒后通电，重启。诶，我什么都没做呀，我就在机柜前坐着，也没人碰机柜呀！肿么就断电重启了，

然后又看了log，发现其他机柜切换到UPS电源供电了一小段时间，交换机的机柜是没UPS的，明显是断电了，但是我人在机房，没人碰设备呀
怀疑是插头接触不良，换了机柜里的排插。（其实想想就不太可能，接触不了还能定时发生？）

第三晚还这样，
第四夜还这样，
诶~神奇了，这是什么超自然现象？

难道是进户线有问题了？想起电线是从隔壁联通机房进来的。
于是跑联通的机房看看他们到点会有问题没？发现这边也是每到那个点，就自动切换到UPS供电。（联通给交换机也配置UPS了）怀疑是电路有问题，时不时断电。


于是，第五晚守在隔壁了。。。一夜无事！！！
诶？？！！！这是神马情况？
然后就再也没事了，断电情况再也不出现了。。
足足好了1个月。直到下个月的运行商派人来例行检查了以下设备后，又出现上述问题了。

额，这是神马情况嘛！！
我去两个机房看了一下，诶，又好了，电信不掉线了！
抓狂了都！！完全是玄学呀这。
只要我进过联通的机房一次，电信的掉线问题就能解决。。
我居然还有防掉线的功能？

最后只好挨个问机房隔壁的几个宿舍有没有发现在那个点机房有没有奇怪的现象。
他们有人说感觉会掉线的日子里，机房不是那么吵！！

然后在我努力研究调查下，终于知道事情的真相：

========真相的分隔线==========
机房的供电是这样的，红色的是电线，紫色的是一排插座

电线是后改造的从室外的桥架上引入的明线，隔壁是电信的机房，因为进门的墙是承重墙巨厚还有钢筋，布线的时候为了省力，就只从联通这屋进了线，电线到插座高度后，打洞到隔壁。

联通机房隔壁宿舍的嫌睡觉时机架散热风扇太吵，就用偷偷用卡把门捅开（那种A级锁，很好撬的），睡前就偷偷把机柜的风扇电源拔了，早上再偷偷插上。。因为机房有空调，拔了也没导致设备过热。但是。。。插机柜风扇的那个插座是进户第一个插座，就是那个孔的位置，他拔插时插头会带动插座，导致里边没接好的电线在连接处断开一下。


为什么周五周六有时没事，因为他们可能周末集体出去了，晚上不在宿舍没人拔插头！
为什么是10点多，因为快睡觉了，才去拔插头。
为什么其他时间不定时，因为他们不一定什么时候想起来插回去。
为什么我进去一次就没事，因为我出机房后，会用钥匙反锁门，他们捅不开了，而其他人出来不反锁，只是关门，他们能捅开。

其实现在回想，最诡异的就是，我第一次蹲在联通机房的那一晚（第五晚）他没来撬门拔插头，不然也不至于追查这么久。

又想起来一个：
【关于锐捷和交换机的事】

学校某一天开始，大量用户正常上网情况下突然掉线，再次拨号时认证停顿在“寻找认证服务器”，之后提示框显示“认证失败”。但是有人发现锐捷认证失败后，“禁用”、“启用”网卡后，多次尝试锐捷拨号能够成功认证，但是在上网几分钟后会再次掉线。

锐捷的认证过程就不写了，看这个个问题的估计都大概知道。
先考虑，锐捷认证服务器故障，看了下，CPU占用率60%左右波动，内存占用2G左右。（这渣渣服务器啊。。占用这么高也是醉了）ＲＧ－ＳＭＰ正常，加密狗也没问题。看来服务器没事。

那估计就是网络环境故障，看了下核心交换机到认证服务器之间的网，物理连接没问题，流量看起来也挺正常。
那估计就是核心交换机和用户终端交换机的问题。

然后发现，核心交换机到物理选课平台的服务器间最高峰时一秒快3万的封包。。。这肿么可能嘛，结果联系了那边，到服务器上一看，恩，服务器被人拿下了，被放了好几个成人和赌博网站在上边，还发现有挖流量矿的代码，还被拿来D别人，还被放了个SMTP服务器在发垃圾邮件。里边的学生个人信息被下载都不算事了。

断开与他们的链接后，CPU负载降低，但是认证还是失败。

继续查，发现另一个到行政楼的接口流量也很高，大约每秒1.5W的封包
show arp一下查看，发现一堆arp未完成报文，在Incomplete状态在ＩＰ地址无法找到其对应的ＭＡＣ地址时进行转发，占用了交换机内缓存表。于是猜，要么中毒，要么出现环线，然后就查呀查，发现基础交换机上WLAN102、103流量异常，那就继续查呗，最后发现，某逗比做了这么一件事。

这个基础交换机是直接给这层供网的，大办公室留两个口，小办公室一个口，他们自己用交换机再分。
学校机构调整，部分办公室从新分配了，本来有个大办公室是，两个部门同时用的，他们每个部门自己各占用了一个接口用。后来换给另一个大部门了，他们搬家时，看到有两个接口，于是把这两个同时插到自己的集线器（居然连交换机都不是）上。

始作俑者还特肯定的和我说，这样可以加快网速，可以有双倍的带宽。
我和他说这样不行，他还不行，非说我不懂电脑了，他是在XX之家看到的，还说之前办公室里就这么接，就没事，网速还快了。（后来发现，他原来办公室其中一个接口，交换机端的插头松了，插了等于没插，网速什么的，只能说是心理作用了）
什么时候集线器能当路由器用了。。
什么时候，带负载均衡的双WAN口路由器，只卖20块钱了。。
想多玩多播起码你也要设置下吧，直接插有个毛用。。
不怕遇到小白用户，就怕遇到半懂不懂还装懂的。。

白丁

以前做windows技术支持，一直调试crash dump。就我个人的体验，有关线程安全的dump是最难调试的，来无影去无踪，看到的就是一坨已经被破坏的现场（dump），然后你需要在大脑中还原案发经过。

有一天香港某大公司（名字不透露了）上了一个case，他们自己的一个应用在生产环境中会莫名奇妙地crash。当时我就想：你自己应用crash找我们干什么，肯定是你自己代码问题，而你还不给我看你的代码！

所以几个难点：
第一，没有客户代码。
第二：客户用的系统是NT4！NT4什么概念？就是没有pdb文件的，符号文件只能对应到函数入口，对应不到具体的源代码行号。你只能把整个函数的汇编都读懂才能知道crash的地点是在做什么事。
第三：只有dump，不可能设断点调式，因为根本不知道如何重现。

反正就这么读了几百上千行的汇编（此处省略两千字），最后定位crash的地点，能看到进到EnterCriticalSection的api之后发现这个CRITICAL_SECTION结构其实已经坏了，然后就挂了。从heap结构可以看出似乎那个heap block已经被用作它用了，所以有可能那个CRITICAL_SECTION已经被delete了。

然后看谁管理这个CRITICAL_SECTION的， 发现是msvcrt，还是VC5的。好吧去找代码，还好那个代码是找得到的。然后就把所以处理这个CRITICAL_SECTION的代码全部找出来，把所有代码在不同线程中的不同执行顺序都排列出来，最后发现在某一个特殊的执行次序下会有一个race condition，导致这个CRITICAL_SECTION会被过早delete掉。还好一开始就怀疑是线程安全问题，入手方向没错。

好吧，最后居然是vc runtime的bug。当初错怪客户了。

调完这个bug的副作用就是之后看到汇编就想吐。看看现在c#的调试那根本不是事。

白丁

评论里信誓旦旦要小护士的兄弟，你真觉得长着一张工程师脸的你能搞定么？ 木有高富帅的命，却得了高富帅的病……洗洗睡吧亲，一个成功的工程师是注孤生的……

XXXXXXXXXXXXXXXXXXX
网络硬件相关
现象：
某医院部署的网络，不定期会有半夜断网或者不稳定情况，但天亮就会恢复，客户投诉抱怨。

调试过程：
现场查看全部网络硬件正常，查看log发现有一台汇聚交换机有反复重启动作，在重启前有高温告警。于是重点关注该机器。

该机器放在一个机柜中，机柜在一个小储藏间的角落里，储藏间不大，一边还摆着张破沙发，正好可以坐着用电脑调机器，但是实在查不出什么可疑情况会导致过热，因为投诉等级较高，于是连夜蹲守。

第一夜无事。
第二夜无事，到半夜，忽然进来个小护士，吓一跳，说，哟怎么有人啊，然后就走了。一夜无事。
第三夜无事，到半夜，又来个小护士，探头看一眼走了。一夜无事。
第四夜无事。
于是告诉院方，发现问题马上打电话，回家。
第五夜出事，赶到时已是早上，网络已经正常，查看log发现还是过热告警重启，时间在半夜3点多。联想到前几天的小护士，于是问院方半夜是否有人进入，答一些值夜班的护士会偶尔在里面休息。
于是找到进去的小护士，问是否动交换机，答没有，问进去后做了些什么动作，答只是睡觉。再追问，除此之外呢？答：就是那个排风扇太吵，睡觉的时候把电源拔了。

她把机柜的冷却排风扇电源拔了！
她把机柜的冷却排风扇电源拔了！
她把机柜的冷却排风扇电源拔了！
她以为就是个通气风扇！

居然睡醒走了还知道再插回去 〒_〒
你有胆拔插头你倒是别插回去啊…

EEEEEEEEEEE分EE割EEEEEEEEEEEEE

再说一个吧。
研发的一块新电路板，调试正常，往机箱里面装，装上螺丝拧好后不上电了，没有电压，确认是电源短路保护。

把板子拆下来，又能用了。
装上去，又不能用了。
跟白鹿原里白孝文在窑洞里穿裤子一样。

机箱是金属并且接地的，检查了全部连接，电源肯定木有碰到地，但是用万用表量的明明就是电源地短路，而且就是裸板能用，带机壳就短路，于是怀疑螺丝。

螺丝都拧上就短路，都拆下来就正常。
然后挨个拧螺丝，定位到某个螺丝。
那个螺丝一拧上就短路。
但是电路板正面反面都是地，螺丝本来拧上去就是为了接地用的，怎么会把电源短路了呢……
这tmd不科学啊。

仔细端详该螺丝孔，发现内壁有些黑，凑近闻略有焦味。心里大概有数了，一查pcb图，果然，6层电路板，内层电源层的铺铜几乎直接铺到了螺丝孔，安全距离只留了一点点。

其实本来也没什么，螺丝只是固定用的，不会和螺丝孔内侧有什么触碰，好死不死的那块板子那个螺丝孔公差偏大，螺丝拧上去是没有完全对齐的，直接卡到了螺丝孔内壁……使劲一拧，就像刀一样切了进去，碰到了内层电源。

所以，所有灾难，都是一连串小概率事件的巧合扎堆，搞科学，也得信命。

白丁

差不多10年前，我们做了一个ARM核的芯片，据说还是国内第一批用ARM7做的，还挺高端，带有很多安全功能，当然安全就意味着难以调试，整个系统全部打散，不能分块。俺负责前端设计，系统，硬件软件驱动等杂七杂八一堆工作。

然后芯片流出来了，封装回来，几天几夜的调试，功能都正常了，那个高兴呀，第一个芯片就成功，奖金有了！

不过做稳定性测试时候有一个问题一直困扰着，这系统总是莫名其妙的有时候启动不起来，概率有个百分之几左右。上电就是不LOAD。而一旦起来之后，就很容易了。

反正功能设计，硬件，驱动都是俺的，那就调呗，软件，硬件，电路，仿真，研究了好几天，抓狂，无解。又整个系统不能分块，我都开始怀疑是不是ARM核的问题。。

又做了一个不断重启的测试系统，不断啪啪响上电断电，针对上电的情况作了统计。得出结论就是，上午不启动的概率高，下午不启动的概率低，晚上不启动的概率高，深夜不启动的概率低。。。。。和饥饿程度快挂钩了。。。

那时候那个抓狂啊，怀疑是什么干扰的，连屏蔽房，隔离电源啥都整出来了。就是没头绪，而公司给客户演示的时间快到了，要是现场挂掉就丢脸了，心里那个急啊。那段时间，每个深夜，公司里就是我座位上啪啪啪的声音------继电器的啪啪声。
接下来一个周日测试，公司空调坏了，汗流浃背，脾气极坏，几乎就要摔板子了。不过发现这天运气非常好，成功概率很高。没头绪，直接抽上烟，看着板子发呆，不知那根神经搭错，直接把烟头对着芯片戳上去！咱第一个亲生芯片！！如果不行了就掐死它！！！结果发现怪了，戳了烟头，启动哗哗的，每次都OK。遂怀疑是尼古丁过敏或者是温度原因。拿着烙铁烫着它，每次必成。于是送进高低温箱，做温度曲线测试，发现环境温度40度以上，成功概率极高，刚好碰见今天加班没空调，平均温度高，所以表现良好。而启动起来因为系统一发热，所以后面启动就容易了，温度一凉下来表现惨不忍睹，敢情这芯片是非洲来的。

有了方向就好说，先解决DEMO，给领导好看。遂做了一个电热丝发热电路，贴在芯片上，用单稳开关控制，一上电就加热，然后不断自动啪啪啪对芯片重启，一旦芯片重启成功了就断开发热电路和重启电路。进入正常运行情况。系统搭起来一测，效果杠杠的！！！基本都能保证几秒钟内就能启动，公司上下一片赞誉。 于是，领导拿着这套带着电炉丝的系统去做报告，销售拿着这个电炉丝Demo去给客户演示，取得极好成功，老板都在准备后续的销售计划了。俺心里急啊，总不能出货产品也带着电炉丝吧。。。。

静下心好好分析，和温度有关，又是随机故障，应该很可能是哪个地方悬空，存在不定态的问题，外面的电路是不可能了，前端模拟加入随机量也不能重现，那很大可能是后端的人搞的鬼，遂拉来后端人员(暂且称为C公司)，检查扫描链和测试电路，果然发现有一个寄存器没有初始化复位。于是后面的情况就简单了，往扫描链中灌入一串数据，把未知量洗出来。成功！！！

所以我们第一代的产品，主芯片旁有一个奇怪的芯片。据线人报告，有竞争对手和盗版者都认为这是安全反盗版电路，因为拆掉这一块，系统工作就时不时的异常，抓不到规律，可能包含短时间正版验证，长时间正版验证，随机正版验证等高精尖反盗版措施。反正无法破解。。。。

俺笑而不语。图样图森破。
---------------------------------------------------
至于说为什么寄存器没有初始化复位没检查出来，我也不知道，这是人家C公司做的后端，他们的软件自己加进去的电路。而据说这C公司虽然牛，但那时候后端服务还是新的，软件也是新的，刚进国内，给我们一个特惠价做白老鼠。。。

白丁

---------------------------------------------------
至于说为什么寄存器没有初始化复位没检查出来，我也不知道，这是人家C公司做的后端，他们的软件自己加进去的电路。而据说这C公司虽然牛，但那时候后端服务还是新的，软件也是新的，刚进国内，给我们一个特惠价做白老鼠。。。
---------------------------------------------------
至于说为什么寄存器没有初始化复位没检查出来，我也不知道，这是人家C公司做的后端，他们的软件自己加进去的电路。而据说这C公司虽然牛，但那时候后端服务还是新的，软件也是新的，刚进国内，给我们一个特惠价做白老鼠。。。

白丁

写一个热乎的，刚发生的：
写JS，自己手机没电了，拿同事老张的安卓机调试，很简单的获取用户微信昵称，结果死活获取不到，一直显示为null。应该是跨平台问题，因为之前在自己iPhone上是没有bug的，拼命看api文档，但是都没提到这方面。急死我了。

———————8.21更新—————————
刚刚老张告诉我他的昵称就是null。

———————8.22更新—————————
A：“听说老张昨天被同事打死了。”
B：“哎。前天还发朋友圈呢。”
A：“是啊，年纪轻轻的，挺可惜的。”

————————说明——————————
前面夸张修辞，老张最后当然没死，腿打断了而已。
有兴趣的可以试试alert(null)和alert("null")~

白丁

评论里有几位朋友对于我提到的BIOS有上百万行源代码表示不可能，甚至有一位朋友提到BIOS就是个boot loader，要那么多代码干什么？我想我有必要在这里做一些简单的说明。

在说明之前，我首先要申明一下由于我2010年就已经离开BIOS行业了，并且之后的日子我并没有持续的去跟踪最新的技术趋势，所以我对于目前的最新情况并不了解，事实上这个行业的知识刷新速度看起来非常快。所以我这里说的其实还是基于我当年的知识构成。

首先，目前的BIOS都是基于UEFI的新一代BIOS。这类系统本身就具备十分强大的功能。完全可以视作一个小型的操作系统，有自己的shell，自己的drivers，自己的app，甚至自己的图形环境。这样的系统的代码量自然不会小。

其次是因为x86系统的历史包袱非常非常严重，而bios作为最核心的系统固件承担了太多的历史兼容性的责任。举个例子，就是对于usb键盘的支持，大家可能会简单的认为，支持一个usb键盘那不是太简单的事情么？的确是这样，但是个人电脑有一个非常非常重要的原则就是兼容性。具体到键盘上，如果你现在找一个古董级的PS/2接口的键盘，然后把它接到现代的主板上，假如你的主板已经没有PS/2接口了，那么买一个转换头，然后再接上去你会发现这个古董级的硬件仍然可以使用。是的！对于我们用户而言，这是完全符合逻辑的一件事情。但是对于bios开发者而言，这就是一个很要命的问题了。原因很简单，我们暂时穿越到几十年前，那个年代的电脑主板上都有一个叫做8042的芯片，用来控制诸如键盘这样的外设，那个时代的开发者通过读写60H以及64H端口来访问键盘，然后那个时代的汇编BIOS则提供了INT 9H中断来为应用程序提供键盘服务，在几十年前那个时代，这一切是很美好的。那个时代的操作系统DOS就是这样来访问键盘的。现在让我们回到更加美好的现代，由于历史兼容性原则，所以现在的每一台计算机还必须可以安装DOS，还必须让DOS或者运行在DOS之上的应用程序可以无差别的运行在现代的计算机之上 - 可是，大家是否知道，现代的计算机压根没有8042这块芯片！更要命的是，后来人们发明了一个叫做USB的新玩意儿，基于这个新玩意儿的键盘根本不会接到60/64端口上，而且这个新接口的键盘采用的编码与过去PS/2接口的编码完全不一样！那么如果不做任何处理的情况下，那些过去年代的软件压根不会认识新的键盘，所谓的历史兼容性根本无从谈起！所以我们伟大的bios这个时候就扮演了救世主的角色了，bios会做很多处理，以现在的角度看，现代bios模拟了一个PS/2键盘：现代bios一边读取来自USB键盘的信息，一边将其转换成那些古老软件能够识别的键盘编码，然后再中断系统，写入内部的60/64端口的缓冲区。大家也许会发现，所有的现代bios里会有一个设置项，一般叫做legacy USB Support，默认值就是Enable，打开这个选项你才可以在DOS下使用usb键盘。当然，具体的实现过程异常复杂，涉及x86处理器最神秘的SMM模式，我们就不展开讲了，这已经远远超出本文的初衷。所以一句话，bios的代码非常复杂，还要包含大量的历史兼容性代码，除了我们上面谈及的键盘问题，还包括比如INT 10H的屏幕服务，据说直到Windows 7的安装程序，还有一小部分使用INT 10H来写屏。那么我们的bios就必须包含这些可能有些用户一辈子也用不上的服务。代码量刷刷的就上去了。

--------------------------

每次想起这个bug，虽然很多很多年了，我仍然满脸都是泪水啊！

当年做x86 BIOS，客户是长城电脑。有一回我们的新版本发布给他们后进行系统重启测试，就是安装好操作系统后反复不停的重启机器，看看重启几百上千次后情况如何。原因是客户买了电脑每天用，至少得保障人家用个俩三年没事吧。

结果我们的新版本重启到一百多次的时候挂了，现象就是开机黑屏，没有任何输出，就和当年的CIH病毒发作一模一样，经验判断系统压根还没有boot OS就跑飞了，我们自己测试也是这样，而且一旦出现问题就只能重新刷BIOS

这个bug非常难调，因为当时我们的版本将近300万行源代码，大概2%的汇编与98%的C，几千个源文件，光是用来参与build过程的工具就有十几个。而且这些工具都是自己写的，构建项目的时候先编译这些工具，再去用这些工具加编译器来生成最后的ROM文件

并且更加恼人的是，我们当时没有source level的debug tool，甚至连汇编级别的单步调试工具也没有，
压根没法对代码做step into/over，更没法加个断点。。。当时可以用来调试BIOS的工具有两个，一个是Intel自己内部用的ITP，这个是人家公司自己的，一般不给外面人用，当时我们公司与I公司的关系尚处蜜月期，给了我们两个，但是当时被Chipset team霸占着做porting用；另一个工具就是American Arium（这家鸟公司不知道现在还活着不），这个东西说白了就是商品化的ITP，因为目标客户少，所以价格巨贵巨贵！一套系统价格几万美金，而且每一代CPU都要换一个插座上的适配器，这个适配器又是一万美金好像，还不太稳定，用着用着就挂了。。。我们公司当时有俩，但是因为没有买新一代处理器的适配器，于是只能吃灰了

于是我们唯一的调试手段就是serial debug，就是系统启动的时候会通过port 80把一些重要信息打出来，然后我们根据这些信息判断执行到哪里了，系统的情况如何。这类似原始的printf打印。如果要看一个变量的值或者验证一下我们的判断，就得重新写代码，在需要的地方加入调试语句，然后花上半个小时rebuild bios，再重新烧录，再上电运行看看打出来的到底是啥。如果有疑问，或者发现这里没有问题，又或者有了新的思路，重复上述过程。记忆中整整一个礼拜，我们都在不停的看debug info，反复烧录bios 哭啊！简直不是人过的日子！

最后发现系统可以成功的跑过PEI，到了DXE阶段的某个环节，突然就像心脏骤停一样，跑飞了！去看疑似跑飞的DXE Driver，是个很普通的平台硬件初始化程序，没什么疑点，压根没有头绪。那段时间，几乎每时每刻都在想着这个bug，实在是茶饭不思，根本没心情做任何事！

就这样差不多过了俩礼拜，经过了无数次的重启与烧录bios，以及猜测，验证，被否定，再猜测，再验证，再否定。。。。。的过程后，我们终于发现了问题的原因：

大家可能还记得电脑主板上有个CMOS，传统上用来存bios设置，但是现代的系统已经逐渐弃用这个东西。我们现在的bios芯片都是可擦写的，也就是用程序可编程。bios大小是8MB，里面会规划好，哪里是code，哪里放设置等等，然后代码里有专门写flash的函数，让大家可以保存一些东西，比如你想用硬盘还是光驱启动等等。同时系统每次启动也都会自己写一点没什么鸟用的信息进来。

问题就出在这个写flash的函数上，我们后来发现，这哥们算错了存储区域的地址，导致写很多次后终于越界，误写到了人家代码区，把人家好端端的代码给写的乱七八糟，就如同当年CIH破坏系统的方法一模一样，照这样哪个机器能点亮才怪呢！又因为每次系统写的信息不一样，比如启动时间就不太一样，所以越界需要的次数不是恒定，更加重了我们排错的难度，泪啊！

maychang

好！

白丁

小的是和另外几千人给一个工业母机做软件的。这个母鸡差不多5亿人民币一台，一般大宗生产需要个百十来台满足产量需求。


一台母鸡停产一秒就亏150多人民币。一个软件bug造成一个母鸡停产一天一套上海内环三居室就亏没了。所以我们每写一行代码都是战战兢兢…


有天一线客服反馈一个客户怒得拍桌子的问题，一个母鸡精度会突然下降100%，检测精度的传感器报警，导致母鸡停止下蛋。按照故障查处协议，发现重启系统就好了。然后这个情况一周出现一次，不固定。每次出现就损失一台奔驰E系…

开发部门紧急安排人手排查。虚拟母鸡模拟，根本不会出现这么极端的问题。各种静态动态分析控制精度的源代码，都没有问题。硬件部门排查相关传感器，也没问题。在内部真实母鸡上还是无法重现。绝望之下还查阅了当地地震纪录…

于此同时，派我到客户那儿，在出事母鸡上结合总部大牛远程会诊，仍然没有头绪。一环套一环的程序上，都没问题，每个输出输入，都正常。然后哪天，duang，读出的精度就跳了。（当然物理上没有duang这一声），一周后我灰头土脸回来。


算了，最后客服建议客户重新安排维护时间来避免独立重启。赔送了客户付费应用。并说开发部门对这个问题需要从长计议。

三个月过去了，某天在食堂偶然听到坐对桌的硬件部门人扯淡他们有个供应商刚汇报了他家寄存器发现了bug，在某一个地址上写不进去，但也不报警啊！听了真是要报警了！

然后我们软件这边就电光火石般开窍了…一看出事母鸡果然用的是那个批次的板子…别的母鸡虽然也用那个板子，但不会遇上那个地址…这个倒霉催的母鸡恰巧累计一段时间就会遇上一次…一个数字正常进去出来就给截了一半啊…
后来给那个母鸡升级了那个板子的固件就再没问题了…

白丁

实验室的妹子给我发消息：你的设备在群脉冲时怎么感觉显示有点跳啊(不频繁，偶尔有一两下)。
我去看，实验过程中像在有人按按键一样，显示自动在翻屏。当时第一反应是按键部分受到干扰了，把按键上的电容由0.1uF改成了0.33uF。现象倒是没是没有重现了。但怎觉哪不对。
第二天，实验室妹子又给我发消息：快过来，你的设备打静电时随机出现复位。一个周期内有时复位，有时又没事！
复位！还随机复位！！我赶过去看了现象，认为是复位电路受到干扰。

加电容，改电阻。无效！
把复位断开，无效！！
打开PCB文件，改电源线路，无效！！！

就这样两天过去了，没招了。说好的下周送检样机去现场联调呢，吃不下，睡不好。
项目负责人(副总工)落井下石，群发邮件召开会议，会上对我一阵批斗，说我硬件不行，并通知没法送检，原因是硬件有问题(实际原因是他家忙着搞装修，软件根本赶不出来，软件测试报告显示有73处bug，外加七项功能缺失)，需要调整到一个月后。
我肯定不服气呀，但又没办法，只好仔细查看原理图，现在怀疑对象只剩下了下电检测(当电压下降到一定值，设备进入低功耗模式)。我把下电检测的器件拆除，把MCU的IO上拉到电源。再去实验，结果合格！！！于是对下电检测进行整改，发现问题依然解决不了。
脑抽想到群脉冲时显示乱跳，就像按键有人在按一样，便怀疑到软件没有作延时或防抖处理。
TMD软件工程师(项目负责人)居然不给我看代码，说软件不关我屁事。让我做好自己的事。这让我怎么查！！
闹僵了，项目负责人打报告到常务总监，说我有问题不去查，还要干涉他的工作。我当时内心一万头草泥马。
只好请来了总工与研发经理，说明了情况，总工说那就看看代码吧，和项目负责人沟通完，于是我们仨挤在电脑前一看源程序，瞬间奔溃。

按键检测没有防抖处理！
上电检测没有延时！
下电检查没有延时！

当场让项目负责人加了相应代码后，再做实验全部通过。

梁子算是结下了！

ljj3166

很有意思啊

白丁

网络狗，搞运维的时候曾经帮某银行定位过网银问题，很逗。
银行访问自己的网银都可以通过内网通道，这是背景。某领导一天在行内通过互联网登陆个人网银，发现页面半天打不开，叫人调查。
各部门测试半天，我靠！好多电脑打开网银登陆页面都得十秒左右，时好时坏。当时行内部署了比较全面的性能监控平台，监控了包括网络 应用 交易各种性能，最外侧监控触角覆盖到了运营商入口，但当时看各种指标都正常，而且也没接到什么用户投诉。
我们搞虚拟机各种测，发现从行内第一次访问基本都会有问题，从其他地方只是偶尔出现。用虚拟机测试加抓包折腾了好久，终于找到了问题。网银登陆页面使用的某国外厂商的证书，首次访问需要去更新证书吊销列表，而厂商域名对应的十多个IP呢，其中一个被墙了…只要被解析到该IP，访问就会出问题。
不了解该厂商的权重怎么配的，但是国内多数用户不会被解析到该地址，而且厂商自己不知道那个IP被墙了。于是该行自己的互联网就成了最典型的倒霉蛋…
后来联系该证书厂商，屏蔽掉那个被墙的地址之后果然就好了

白丁

搞单片机软硬件的，有次有个同事画的板子，GSM模块，每次都是找不到信号，然后重启。因为搜索信号需要较大的电流，一开始以为只是简单的驱动芯片有问题，换成大电流的。不重启了，但始终搜索不到信号，好容易搜索到了十几秒就断开了，当时以为是GSM模块买到假的了，但不确定，就找同事问有什么问题，因为模块拆下来放到以前的老板子上就好用，所以我就一个劲的问他是不是硬件问题，他老是说没问题，最后他烦了，扔给我pcb图让我看。我也是从头看到尾，测试了2天，也确实没问题。只能对比老板子。最终发现一个细节，老板子的信号线很短很粗而且只有一面，新班子他很细就算了，居然还打了4个过孔，正面反面，我于是用小刀划开线，然后用一根铜线把信号口和天线直接短接，一切正常（天线处要求线粗点而且不能有过孔，尽量短）。那天下午我短接了20多块板子，全部正常了。我去，当时我恨不得把那个同事的头塞进他XX里。这些天老板一直认为我软件有问题，骂了我无数次。由于是小公司，产品也是小批量自用，最后处理是，50多块板子全部切断用飞线。我弄了20多块，剩下的他自己干吧。从此，他做的东西，我都是要到pcb板图自己好好看看，免得出了问题。事实证明，他还是没长记性，后面还是出了好几次类似问题，我能感受到他之前的同事被坑的有多惨……

574433742

不好意思，由于帖子太长，我只能手动点个赞，，表示支持你。。。

白丁

歪个楼，说个SCADA工程投产的关键时刻突发的bug，论技术含量，它无疑是最low的，但绝对够刺激。

N年前的一天，晚10点，甘肃戈壁滩上的某处工艺站场，现场一片忙碌，根据工艺人员的测算，工艺介质还有半个小时就要进站了，介质进站就表示站场正式投入运行。我和我们部门经理，作为站场核心控制系统——SCADA系统的集成商，2人蹲守在站控室的主控电脑前，做好了72小时保投产的准备。

随着时间一点点逼近，控制室的气氛越来越凝重，对讲机里丝丝拉拉的呼叫声、调度电话的铃声，此起彼伏，我和经理也一脸严肃地坐在站控台旁，内心既轻松又紧张，经过一个多月的紧张安装与调试，站控SCADA系统早已准备就位，该忙活的都忙活完了，剩下的就看它的了！

10点05分，报警器突然传出沉闷的报警声，三条报警出现在SCADA软件的监控屏幕上，三条报警都指向同一个设备，我快速浏览了一下控制流程图，其它设备一切正常，单只这台设备的状态出现了变化，我的第一反应是，又是哪个傻逼在现场乱动设备了。

这套站控SCADA系统是由我亲手组态安装的，每一个信号回路、每一个信号、每一个控制命令，我都亲自测量调试过，我敢保证系统里显示的所有数据，一定是对现场工况的真实反映，所有的数据和操作，一定是准确可靠的。

我猜测，这台状态发生扭转的设备，肯定是现场人员手动操作的结果，没有调度令瞎特么动，找骂呢，也不看看现在是什么时候，我还幸灾乐祸呢。

10秒钟不到，几千公里之外的控制中心的调度电话就打过来了，什么情况？报告原因？

离设备最近的工作人员迅速赶过去，用对讲机汇报了检查结果：设备一切正常，没人动它，现场指示一切正常！

现场指示一切正常，我心里咯噔一下，不会吧，设备没问题，那就是SCADA系统有问题呀，数据错误那可是重大失责，极有可能导致生产事故的，这可不是闹着玩的。
腾的一下我就站起来了，抓起防爆对讲机就向200米开外的工艺区冲去，我必须亲自确认一遍设备状态，果然，机械指示没问题，电子指示也没问题，各种装置也在原来的位置上，没错，设备没问题，完了完了，回去查系统吧。

我以最快速度飞奔回站控室，一头扎进机房，迅速检查了一遍上、下位机的数据，PLC、实时数据库、HMI三者数据一致，数据流正确，系统没问题呀，我在脑子里头快速过了一遍数据流程，究竟是哪个环节出问题了呢？

PLC程序中设备的控制逻辑是按模块封装的，要出错早就该出错了，不会拖到现在，即使真出错了，也得是现场几十个同类设备一块出错呀，单是一台设备出问题，肯定不是PLC程序的问题，排除。

实时数据库出错的可能性也不大，数据点在数据库中是哈希分布的，不存在逻辑关联，同一设备的所有数据点同时出现错误的概率太小了，我还不至于点背到这个程度，再者说，实时库中的数值与PLC是一致的，说明数据采集程序运转也是正常的，排除。

HMI显示的都是实时库发布的数据，我手动修改了几个故障数据点，HMI立马跟着变化，数据发布和显示功能也正常，排除。

上位机和下位机都排除了，剩下的就是PLC IO模板及其之后的环节了，先排除IO模板吧，短接测试最简单有效，半分钟之后得出结论，IO模板也没问题，排除。

问题肯定出在现场设备与机柜之间的信号回路上，没得跑了。

我咽了口唾沫，转身抄起了万用表，在PLC机柜缜密排列、密密匝匝的电缆与信号线中，找到该设备的所有输入回路，逐一量过，果然，信号回路的电流电压与现场设备的状态严重不符，与HMI显示的错误结果一致，问题找到了，电缆传过来的信号乱套了。

不会是信号电缆断了吧，这是我脑子里闪过的第一个念头，现场设备与机柜之间的所有线路我都亲手调校过，每一台设备我都开盖测试确保接线规范牢固，单体调试和逻辑联动也是反复做了很多次，这些基本功课我做的一丝不苟，完全可以排除掉接线错误、接线自动脱落等低级错误，出问题的是台进口设备，这类设备之前的表现一直很稳定，信号源出错的可能性貌似不大，现在摆在面前的唯一的可能就是，这条电缆现在断了，或者它曾经断过，后被施工人员只是草草地焊接上了，现在脱焊了。

按照施工规范，信号电缆是不允许出现断点的，然而，献礼赶进度，难免出现加班施工、违规操作的情况，哪个土方施工队开着推土机，冷不丁来上一铲子，干断几根电缆的事情也是不可避免的，毕竟从控制室与设备之间有好几百米的距离，中间隔着很多地面施工点。（电信机房的光缆都会被人挖断，更何况繁忙的施工现场敷设的电缆，每次想到献礼我就蛋疼）

一种不详的预感向我袭来，要真是焊接的电缆，哪我就太TM倒霉了，电缆敷设和仪表安装的活也是我们公司干的呀，尽管不是我的工作，但他们挖的坑埋的雷，最后都得由我们来拆包填坑，而且还特么是在这种关键的时刻，一万头草泥马从我耳边呼啸而过，我不敢往下细想了，一股凉气从后脊梁一路串到头顶。

经理赶过来了，见我正举着万用表，看着机柜发呆，还以为我吓傻了呢，一把抢过万用表就要亲自上阵，他是赶过来保投产的，未参与前期调试，他以为是我的信号回路接线有问题呢，我拦住他，把情况跟他一说，他也傻了，这种狗血的事情，他之前遇到过。

经理赶紧把在站控室外待命的仪表安装负责人叫了进来，瞪红了眼，指着电缆问道，老张（化名），这根缆被人弄断过，你们给偷摸焊上了，是不是，你跟我说实话。

老张憋红了脸，拍着胸脯保证，这根缆绝对是一条完整的电缆，没出过任何问题，无论我们怎么逼问，老张都一口咬定，电缆绝对没问题。

我和经理看老张说的这么决绝，姑且相信了他，这种时候，谅他也不敢死扛。

可是电缆没问题，设备也没问题，那会是什么问题呢，我抬头看了一眼时间，10点19。

冷静，冷静，我擦了擦鼻子上的冷汗，走到机房的小窗口，漫无目的地扫射了一遍厂区，夜色中，几十台相同型号的设备散布在工艺区的各个角落，深蓝色的电子屏如群兽的眼睛，透着幽兰的光芒，死死地盯着我，那台故障的设备就蹲在巨大厂房的阴影之中，眼睛忽明忽暗地眨巴着，仿佛在嘲笑着试图驯服它的主人我突然一个机灵，不对劲，亮度不对劲，其它设备电子屏的亮度是固定不变的，很少出现闪烁，只有这台故障设备的电子屏，如鬼火般轻微跳动，在夜晚黑色的背景下，越来越刺眼。

电压波动，肯定是380伏动力电网的电压波动，导致设备的主电路版出现了故障，我拆过这种设备，它采用的是独立的显示模块，尽管显示模块与IO模块是隔离的，但电子屏都出现了画面抖动，IO模块也不会好到哪里去。

我转身正要往控制室跑，这才发现，站场的主要负责人已经把经理给围住了，经理憋红了脸，应对着各种质询与责难，我赶紧上前，把我的发现与想法告诉了他们，他们半信半疑，这种进口设备，项目上用了这么多，从未出现过这种问题，你确定是设备的问题不是你们的问题，信与不信已经不重要了，不试怎么知道，时间不等人，赶紧请示控制中心，要求重启设备，控制中心回复：现场自行决定。

还决定个屁呀，我抹头就往厂区跑，把这帮人甩在了身后，开闸，断电，等待10秒，合闸，上电，报警自动恢复，数据显示正常。

10点28，故障终于解除了，憋在胸口的一口闷气，终于可以吐出来了。

控制工程和软件工程一样，都是系统工程，一环扣一环，一层叠一层，系统越复杂风险越大，系统工程出现的问题，绝大部分都是多米诺骨牌效应造成的，小故障导致大事故。

多米诺骨牌的触发和传导过程是外显的，小牌推大牌，傻子都能一眼看出问题的端倪，但系统工程是隐蔽性工程，系统内部的结构不是显现的，问题的发生与传导也是不可见的，当故障发生时，大家看到的是倒下去的最后一张牌，看不见故障的源头，也看不清坍塌的全过程，这也是为什么工程师爱说「不是我的问题」的原因，很多错可能真的不是他们造成的。

愚蠢的管理者，会责怪倒下去的最后一张牌，聪明的管理者，认为每一张牌都有作案的嫌疑。

当你被怀疑时，能做的就是自证清白，往下深挖，如果你自己的功课一团糟糕，又没本事找出推倒你的上一张牌，那么很不幸，你就成了那口黑锅，only you。

很多时候，工程师什么都爱学一点，并不一定是求知欲太强烈，或许他只是想看清楚，站在我身后的，究竟是些什么鬼。

白丁

我突然一个机灵，不对劲，亮度不对劲，其它设备电子屏的亮度是固定不变的，很少出现闪烁，只有这台故障设备的电子屏，如鬼火般轻微跳动，在夜晚黑色的背景下，越来越刺眼。

电压波动，肯定是380伏动力电网的电压波动，导致设备的主电路版出现了故障，我拆过这种设备，它采用的是独立的显示模块，尽管显示模块与IO模块是隔离的，但电子屏都出现了画面抖动，IO模块也不会好到哪里去。

我转身正要往控制室跑，这才发现，站场的主要负责人已经把经理给围住了，经理憋红了脸，应对着各种质询与责难，我赶紧上前，把我的发现与想法告诉了他们，他们半信半疑，这种进口设备，项目上用了这么多，从未出现过这种问题，你确定是设备的问题不是你们的问题，信与不信已经不重要了，不试怎么知道，时间不等人，赶紧请示控制中心，要求重启设备，控制中心回复：现场自行决定。

还决定个屁呀，我抹头就往厂区跑，把这帮人甩在了身后，开闸，断电，等待10秒，合闸，上电，报警自动恢复，数据显示正常。

10点28，故障终于解除了，憋在胸口的一口闷气，终于可以吐出来了。

控制工程和软件工程一样，都是系统工程，一环扣一环，一层叠一层，系统越复杂风险越大，系统工程出现的问题，绝大部分都是多米诺骨牌效应造成的，小故障导致大事故。

多米诺骨牌的触发和传导过程是外显的，小牌推大牌，傻子都能一眼看出问题的端倪，但系统工程是隐蔽性工程，系统内部的结构不是显现的，问题的发生与传导也是不可见的，当故障发生时，大家看到的是倒下去的最后一张牌，看不见故障的源头，也看不清坍塌的全过程，这也是为什么工程师爱说「不是我的问题」的原因，很多错可能真的不是他们造成的。

愚蠢的管理者，会责怪倒下去的最后一张牌，聪明的管理者，认为每一张牌都有作案的嫌疑。

当你被怀疑时，能做的就是自证清白，往下深挖，如果你自己的功课一团糟糕，又没本事找出推倒你的上一张牌，那么很不幸，你就成了那口黑锅，only you。

很多时候，工程师什么都爱学一点，并不一定是求知欲太强烈，或许他只是想看清楚，站在我身后的，究竟是些什么鬼。

白丁

从前做一个嵌入式的项目，调试工具巨难用而且随机挂掉，也没有core dump，只能手工添加printf看日志调试bug。有一天出现了一个bug，查看打印日志，修改，第二天同样的bug又出现了，但是在不同的源码处。继续添加日志，查看，修改，这过程重复了n次，每次出现bug的位置都不一样。我突然醍醐灌顶，查看了下printf的源码............tnnd谁把printf函数给重载了，写入还不做校验，会写到别的内存位置上去。就像是我拿个锤子到处敲地鼠，地鼠其实住在锤子里.........

白丁

目前为止调试时间最长的 Bug 同样发生在硬件上。我是本科生，之前没有任何硬件基础，所有 Xilinx ISE 和 Verilog 都靠自学，苦于没有好的文档，学习也不系统。

我们的计算机组成课程要自己在板子上完成一个多周期 CPU，再基于这个 CPU 完成一个自己的应用程序。为了减轻我们的痛苦，教授给我们提供了内容丰富的 PPT 和一系列软核。我本身对硬件的了解只算一般，因此被教授的良苦用心打动，在长达一个学期的时间里，一直跟随 PPT 的指引和提供的代码逐步完成 CPU 的构建，将教授的软核换成自己的实现，并且每个步骤后都用教授的测试二进制指令在七段数码管上打印内存中的图形（这保证了计算、跳转和存取指令都正常运行）。通过不断地实现和调试，我终于建立了对这整个体系的了解。然而最不可思议的事情也在这时发生了。

当我最终完成多周期 CPU 的控制器，并替换掉教授的软核时，我忽然发现测试程序开始出现奇怪的 Bug。首先是某一行的数码管总是无法亮起来——这很正常，一次写成的代码，尤其是 Verilog 这种语言，手残出现 Bug 十分可能。于是仔细看代码，修复，等五分钟综合，下板。全挂了？！这次数码管上显示得完全是杂乱的图形。再次审查代码，又发现一个可能的 Bug，修复，五分钟综合，下板。依然乱码。焦头烂额，再去看代码，完全正确，再也不像有问题，所有的寄存器都好好地初始化了，看综合日志也只有一点时序警告——听说大家都有。将软核替换回去，五分钟综合，一切正常。

WTF？之后的几天，课后时间，我都打开 ISE，对着 PPT 和书一点点静态审核代码。没有问题。用数码管查看 PC 并打开单步开关，但每次有显示时，PC 就已经到了比较后面的位置，之后也自然出错。甚至自己把多周期的状态也显示在数码管上，单步一点一点看，状态转换都正确，只是条件跳转时就是不满足条件。综合缓慢，这样每次决定抽时间调试，都用去两三个小时，还没有任何进展，对我来说实在难受。

动态和静态调试都没有结果，眼看这个实验的 DDL 迫近，我只好求助同学了。他说他也几周没有调通，最后只好向另一位同学“借来”控制器的代码，组合以下，下板通过，交了作业。我如获至宝，开始一点点看这份控制器的代码。将他的代码稍微修正，替换我的控制器模块，下板，一切正常。好。然后开始逐行对比，一点点把他的控制器改成我的版本，每次修改后综合也要几分钟，但至少 CPU 能正常运行了。

直到我发现，他的控制器把 SLT 实现成了 SLTU，并且没有实现 SRLV——而我正确实现了前三者。帮他正确实现以后他的代码也无法正确运行。而把我的实现一点一点调整，减掉 SRLV，不行。移除 SLTU，不行。移除 SLT，不行。然后两两组合，最后发现需要不实现 SRLV 和 SLTU，错误实现 SLT时才能通过时，我已经快要崩溃了。最令人发指的是，我之前用自己的汇编器反汇编了测试代码之后，里面根本没有对以上三个指令的调用。WTF？

不过既然通过了，自然先交了作业。下一次遇到这个 Bug 就是在期末大程序了。

我计划用这个 CPU 写一个生命游戏，因为程序需要在 CPU 里加入了 SLLV 和 SRLV，于是那场噩梦又重现了。幸好学期初有远见，我对这个工程花时间写了一个 .gitignore，开始用 git 版本控制。果断回滚再说。综合几分钟，下板，没有过？！git status 显示我已经 revert 了，git diff 显示没有任何差异。我已经有些疯狂，开始注释控制器中的指令实现，再综合，下板看结果。几个小时过去，我发现这次要注释掉 SLT、SLTU 和 SLLV，保留 SRLV 才能让教授的测试代码运行……

我真的有些绝望。如何在这样的 CPU 上建立应用程序？

冷静下来，我写了一个简单的在 VGA 上显示预定图形的代码，发现图案显示莫名其妙地会丢失一些区域。同时我还发现，之前那份勉强通过实现的 bit 文件在下板后，在我打开单步开关十几分钟再恢复后，也会出现 Bug。这个问题应该和时序有很大关系。

看了 RTL 图，增减指令只是影响多路选择器的大小而已。难道超过了某个大小会触发某个微妙的 Racing Condition？是不是我的时钟源有问题？但我一直使用的是教授的分频软核，而且我也没有这个软核的代码。思考再三，之间也继续徒劳地调试了很久，最终我决定向教授要这份代码。拿到代码，我整理了以下，综合，看到了一个新的综合警告。原来软核会导致综合警告消失？但这个综合警告在很后期，大意也就是时钟歪斜。我想到这份代码里教授自己用了一个 BUFG，这种事情果然还是交给综合器去做比较好？于是拿掉这个 BUFG。综合几分钟后，结果那个警告直接变成了一个无法满足时序的错误……

WTF？这个时序到底是怎么回事？忽然，我想到我可以检查以下时序的链路。果断 grep 了以下 clk 和 clock，令我难以置信的结果出现了。在这个学期最开始的时候，构建顶层模块时，我按照老师 PPT 里的代码，把 CPU 的时钟绑到了一个 LED 上来看时钟的状况？！当时的我 Verilog 理解还很弱，根本看不出这样做会对时序有影响（那时还没有对时钟歪斜的考虑），但现在看来这简直是疯狂。果断去掉这一行，于是再去掉 BUFG，加上正确实现的各个指令，一切正常。我的多周期 CPU 总算是正常运行了。

后来我还遇到了自己汇编器实现的两三个 Bug，汇编代码里的几个 Bug，有手残，有逻辑错误，但无论错误是否低级，对错误的定位都从来不是从静态调试里得出的，而是我忽然想到在某处建立一个测试指标，再观察输出，一点一点缩小范围再定位到的。到我的工程完成，已经是暑假的第二周，拖过了教授延期过的 DDL 一个星期，但也幸好教授仁慈，还接受了我的大程，给分也算得厚道。而此时我在这个工程上消耗的调试时间已经超过两个星期的整个白天了。

总结这次得到的教训，大概两点。一，对于黑箱的工具，要及其重视警告信息，尽最大努力弄清警告来由。二，对于大的系统，静态查错是难以有效的，况且认为有错的部分其实不一定是错误的，还是要通过写测试观测结果缩小范围来确定错误。即使编译过程缓慢，这样做也值得。