放眼望去怎么基本都是纯软件的bug。。。。。。。。广大的硬件工程师固件工程师驱动工程师在哪里?
来吧,我来分享一下硬件相关的bug吧(线路设计,固件,驱动,etc)。在以前的回答中,我曾经零零碎碎写过一些,这里先搬一点儿过来。如这个答案( 怎样让别人明白学习或从事计算机专业的人不一定会修电脑? )里的我的回答。
本答案会继续更新,有空就来写点儿:
==============2014/8/20更新============================
(搬过来的答案,懒得重新整理了) 不严谨的USB驱动撰写者 :
一个英国的驱动高手(56岁的老头),有一次客户报bug说在一家医院里他们的一个USB设备就是没法在新一代电脑上用,而且是时好时坏,没有规律可言。客户派了硬件软件BIOS几个工程师过去解都没解出来。我请到这位高手出马,高手拿到USB设备和电脑后,花了一天的时间做初步验证,然后花了一个晚上写了个小程序模拟那个USB设备的驱动的挂起/卸载,然后花了2小时运行那个程序,发现USB设备的驱动在挂起/卸载很多次以后Windows就会有一定的几率拒绝挂载这个设备,然后他在和微软以及那个设备的厂商联系,花了一天时间确定USB设备的驱动里的一个bug,第三天,USB设备的厂商出了一个测试驱动,问题完美解决。
粗心的硬件工程师
某台式机机型,出厂后大约一年后,开始出现大批量的返厂。返厂的现象惊人一致:主板挂了无法开机,挂掉的是主板上的芯片组。 由于该机型芯片组损坏率远高于其他机型,我们一开始怀疑是客户使用不当(因为最早返回的都是某一特定大客户的在某国工厂退回来的机器),但随着时间的推移,全世界各地都有返厂的现象。于是目标转向怀疑该主板设计有问题。但是,妖异的来了,从工厂抽调数百台该机型进行压力测试(没日没夜跑高压程序,进烤箱,各种设备插拔),就是没有一台机器挂掉。前前后后折腾了一个月,大家都丧气了。最后,好不容易,从客户手中拿到一些坏掉的机器,我们把芯片组拆下,重新植球,检测后发现是芯片里有一部分电路已经损坏,多块芯片组损坏的地方完全一致。最后,我们去检查该主板的设计,发现芯片组的某个输入电源,应该使用1.5V,却使用了3.3V电压。由于芯片组本身质量不错,尽管设计需要1.5V但是在3.3V下仍旧可以忍辱负重工作很久才烧掉,所以这也就解释了为什么我们无论怎么压力测试都测不出来,要等机器在客户手里使用一年左右才会烧掉。 最后,全球召回更换主板,问题解决。
奇异的环境
某台式机墨西哥工厂生产线,操作系统有时会无法download(这边普及一下知识,生产线上的操作系统不是安装的,都是通过网络直接把image下载到硬盘)。该问题在其他国家的产线上完全无法复制。经过多个工厂严格的对比检验(工程师飞来飞去好几个星期),发现唯一的区别是墨西哥工厂生产线上的网络环境使用的是hub(有点穷),而其他工厂使用的是switch(别的富裕一点)。进一步debug发现,台式机自带的网卡的驱动,在用hub的环境下会丢包导致image download失败,而在switch环境下就不会。通过网卡厂商驱动程序工程师debug之后,更新了驱动,问题解决。
==================2014/8/21更新===================
躺着都中枪
某机型,量产后稳定发售大半年,一切OK,用户反映良好,销售订单不断,大家都很开心。不料,从某个月起,返厂的数量逐渐增加,故障完全相同:主板上供电模块烧毁。由于该供电模块应用在非常多的机型中,只有这一个机型有大量返厂,于是怀疑供应商的供货质量管控不佳,某一批次产品质量有问题。供应商被challenge的狗血淋头,使用各种手段验证,得出结论是产品质量控制没问题。我们当然不信,继续challenge供应商,逼得大家鸡飞狗跳。后来,随着时间推移,返厂的机器越来越多,损坏的供电模块广泛散布于各个批次之间,这下供应商抬起头来:总不见得我每批货都有问题吧!好,只能继续debug,供应商对模块进行检测后,告知损坏的原因是长期超负荷运行导致,基本上超负荷连续运行超过3个月,模块就会损坏。我们很奇怪,电路设计各方面都符合标准,为啥模块会超负荷运行?于是,开始各方面排查,经过两个月的仔细研究,把每台返厂的机器的所有config都拉出来做对比,终于得出一个共同点:所有损坏的机器,都是从某年某月某日开始使用了某个新的显卡驱动之后才发生的。神了,显卡驱动能烧毁供电模块?这时候,工藤新一开始附体:如果排除所有可能,剩下最后一个可能,即使它是多么的不可思议,也一定就是真相! 好吧,继续研究,发现这一版的显卡驱动,在调配显卡功耗的时候,会在供电模块的输出电路上产生一个尖峰(电压高达额定电压的十倍以上),尽管这个尖峰时间很短(以微秒计),但由于驱动会不断的调整功耗,导致这个尖峰会极其频繁的出现。所以,如果电脑是24小时开机并一直在运行高压程序的话,这个尖峰的持续出现会导致供电模块的损坏。后来,修正显卡驱动,问题解决。供电模块的供应商感慨道:这真是躺着都中枪啊!
====解释的分割线======有人提到没事不要更新驱动,其实这个有点草木皆兵的味道了。该更新的时候还是要更新的,毕竟新的驱动很多时候是解了不少bug以及提升不少性能的。这个bug当时存在的原因是该显卡第一次内置动态功耗调整,所以驱动开发人员经验不足。后续的产品在驱动开发的时候都会配合硬件工程师一起做测试来保证不出现类似的bug。
========2015/03/23更新=====================
不差钱的土豪也有倒霉的时候
某机型,量产后稳定发售半年有余,忽然从某个月开始,产线上不良率骤然提升,具体表现在某个出厂测试无法通过,不良品广泛散布于各条生产线各种配置上,毫无规律可言。工厂端仔细检查后确认近期没有引入任何新的物料,也没有更改任何生产步骤,产线上的工人也没有任何变动,于是将问题上报。研发人员介入后发现,似乎问题是跟着PCB板走的,因为在不良品上即使更换处理器芯片组,不良品依旧是不良品,而当你把不良品上的处理器芯片组换到良好的产品上,测试就通过了。于是,矛头指向PCB制造厂,怀疑他们品控不良。PCB厂经过两周的排查,确定他们出厂的PCB品控良好,并且他们对不良PCB做过检验,各项指标都在标准范围之内。这下研发人员抓瞎了,问题被推送到我这里。不巧的是,正好没几天就农历新年了,我只好要求工厂把不良品寄给我,我再寄给美国总部的工程师帮助debug(老美不过新年也有好处啊)。随后,工厂停产过年,等待年后复产。大家开开心心过年回来后,老美的报告出来了,经过不良品和良品的检验,发现不良品上处理器的某个控制电压超出范围,导致处理器工作不正常。研发人员进一步检查后发现,原来在那个控制电压上,研发过程中曾经为了debug的需要,串联了一颗 0 欧姆的电阻,而那个电压就是在通过了 0 欧姆的电阻后,压降超出范围导致的问题。随后,经过对不良品上的 0 欧姆电阻检测发现,该0 欧姆电阻的阻值远超spec,原来是电阻厂品控不良啊! 研发通报了该事故给采购,采购立即将该电阻厂除名,问题解决。
解释一下,开发过程中,电路上经常会预留一些0 欧姆的电阻,可以作为监测点来debug。通常来说,量产后,这些0欧姆的电阻都应该去除,改为直连,以节省成本。有趣的是,当初该客户正好处于不差钱的状态,又十分保守,决定在研发结束到量产的过程中,所有电路一条线都不能改,于是这些用于debug的0 欧姆电阻依旧被保留着,直到该问题被发现。
========2015/03/30更新=====================
强势的事实垄断者
前面写了很多量产后的bug,这里写一个还未量产的bug吧,其实这个bug的核心不在于技术问题,而是钱的问题。
某机型,研发过程中的小批量生产的时候一切正常,研发进行的异常顺利。大家都很开心,准备等8月份宣布量产后开香槟庆祝。
6月下旬,按研发流程,工厂开始了量产前最后一批大规模试产,同时对产线进行最后的调试。6月底,工厂开始报问题,这批试产的机型大约会出现千分之三左右的花屏现象,现象完全随机出现,经过数次排查,无法确认花屏出现的规律。咣当!大家都懵了!没有规律的bug是最头疼的,何况现在接近产品发布日期,如果在发布之前无法解决,产品上市就会延期,大家都死啦死啦滴。得,工程师全部驻厂,没日没夜debug,硬件软件固件工程师就在产线上趴着,逮到一台花屏机就开始debug。幸运的是,在产品发布会延期的巨大压力下,工程师被逼出了无穷潜能,居然最后debug出来了。原因很简单:屏幕控制芯片的一个时序不符合规范,有个信号理论上延时不得大于30ms,实测值什么样的都有,最大的能跑到300ms,翻了10倍。大家长出一口气:行了,替死鬼找到了,有人担纲了。
万万没想到的是,当工程师找到屏幕控制芯片的厂商的时候,他们一脸轻松:我知道啊,这个时序我的确没符合规范!工程师当场跳起来了:靠我去年买了个表,你知道你怎么不早说!有毛病的片子你敢出厂!看我不告死你!厂商一脸傲娇:没办法,这个时序如果要控制在规范内,我自己没法量产,因为良率不达标!大家大怒:TMD良率不达标关我屁事,你的片子卖给我你就得达标!不达标我就告你!厂商说:你丫懂不懂,这个规范不知道那个脑子进水的人定的,你要我时序符合规范,可以,良率降4成,我的价格要翻倍!你出双倍价格我就给你达标的片子! 七嘴八舌吵了一个多小时,大家一拍桌子不欢而散。
工程师回来找到采购:TMD采购你怎么搞得,这种厂商你也放进来!采购一脸无辜:你知道么?!这是目前市面上唯一能提供你需要参数的厂商!只此一家,别无分店!你要我换厂商,可以,你把你的参数改了! 工程师说:靠难道赚钱的活没人干?这片子又不是什么高精尖造火箭!采购说:别的厂商有,但人家要年底才能出货,你能忍?
工程师没办法,回去找大老板:老大,这活没法干了!
老大了解了来龙去脉,嘿嘿一笑:能用钱解决的问题就不是问题。采购,你去把第二家厂商拖进来,让他们年底开始供货,然后去跟第一家谈,我出双倍价,让他们供货,等到了年底第二家上来了我们再去治治第一家。工程师,你现在就去跟第二家开始合作,测试他们的片子,确保年底能供上。
最后问题解决了,靠的不是技术,是砸钱,砸钱,砸钱。。。。。。。。。
========2016/01/17更新=====================
一切都是因为不舍得花钱
这是前年的bug了,不过今天偶然想起来了,顺便更新一下。
话说现在4G越来越普及速度越来越快资费越来越低,平板电脑和笔记本电脑也有很多都自带3G 4G 网卡了(俗称WWAN)。厂商都不傻,早早的就开始了研发工作。所以,前年的一半左右时间,我都深陷WWAN bug之中无法脱身。其中有一个,印象极其深刻。
话说这个WWAN吧,测试是个麻烦事,实验室测的真的不太管用,在实验室里测试结果很漂亮的机器,拿到公共场合经常各种毛病,不同运营商,不同地点等等都会影响测试结果。当然,这是普通平板电脑和笔记本电脑首次内置WWAN,各大厂商基本都没啥经验。不比华为这类有着深厚功底的公司,3G上网卡早就做的不要不要了。这不,一个bug就找上门来了。简单点来说,就是WWAN时好时坏,在实验室里啥毛病没有,到了公众场合测试就会时不时连不上啊,飞行模式切过去再切回来WWAN就起不来了啊之类的,非常影响用户体验。更加倒霉的是,debug过程中牵扯到本公司数个部门,关键员工广泛分布于印度美国波兰德国中国台湾等各地,每次开会要凑齐所有相关人员简直痛苦的一塌糊涂。长话短说,debug了三个月之后,在大家都精疲力尽的情况下,终于矛头指向了某软的USB驱动。但因为没人有他们的代码,debug只能靠不断的猜测,各种尝试来试图逼近结果。
此话一出,相关领导全部表示不相信:开啥玩笑,某软的USB驱动存在已有接近10年历史,bug早就被扒的干干净净。。。。小伙你是想偷懒吧?
(此处插播一个传言:传说中,如果你向某软报bug,最终查出来如果真的是他们的bug,那么不收钱。否则,他们会按照技术支援人员在你这个bug上耗费的时间来收钱,貌似每人每小时要收一百多美金,如果由于bug级别提升而需要他们的人员周末加班那就会上升到数百美金每小时,如果再要他们的大牛出马的话就更没边了。由于此传言过于奇葩,据说没人敢于真正尝试随便向某软报bug,都是把bug查到100%有把握是某软的问题之后才敢上报。)
话说,众多兄弟,数十人三个月日以继夜的debug已经精疲力竭,纷纷向领导表示:你不报给某软咱就不干了。领导被逼无奈:报吧,真要花钱就花吧,这么多兄弟花这么多时间,也都是钱啊。。。。。。
bug报上后,把问题机型寄到某软总部,某软指派工程师查看一周后,回复:没错,这是个bug,我们7月份的更新已经包括了这个bug的解决办法,你们等最新的推送就好了。
大家都已经等了3个月了,实在等不起,求爷爷告奶奶,某软终于答应给一份内部测试版的更新让大家尝试。更新包打上之后,WWAN稳定的不要不要的。。。。。。。。。
事后,众人算账,就算某软某工程师一周每天8小时查看这个bug,也就40小时而已,即使被某软收钱,也就几千美金最多万把块美金的事情。我们这里前前后后各个厂家扯进去的工程师都快50人了(包括测试人员),三个月的工作量,怎么都不止几千美金。。。。。
一切的一切,都是刚开始的时候不舍得花钱,于是窟窿越来越大。。。。。。。。。。。。。。
最难调试修复的BUG是怎样的?
发表于:2017-01-09
作者:IT民工
来源:
- 周排行
- 月排行
-   缺陷管理规范及流程
-   认识软件中的Bug
-   常用的bug管理工具
-   软件用例写作与缺陷管理
-   开发不改bug?给你支个招
-   如何编写更佳的bug report
-   面对Bug的正确姿势
-   实例!软件缺陷数据度量和分析
-   深入BUG分析
-   购物系统测试缺陷报告
-   缺陷管理规范及流程
-   国内外最好用的6款Bug跟踪管理系统
-   消灭Bug秘籍:如何处理大型软件中的错...
-   史上最臭名昭著五大软件Bug