Netscreen的岁月 之十二 NS-200危机

作者 | 2011-10-06 13:53 | 类型 行业动感 | 18条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 Netscreen的岁月

  1. Netscreen的岁月 之一 初识邓锋
  2. Netscreen的岁月 之二 Egis Communications
  3. Netscreen的岁月 之三 防火墙做错了
  4. Netscreen的岁月 之四 思科啊思科
  5. Netscreen的岁月 之五 一堆新高管
  6. Netscreen的岁月 之六 研发体系
  7. Netscreen的岁月 之七 NS-1000
  8. Netscreen的岁月 之八 中国筷子楼
  9. Netscreen的岁月 之九 Efficient Networks
  10. Netscreen的岁月 之十 世界第一的防火墙芯片
  11. Netscreen的岁月 之十一 上市
  12. Netscreen的岁月 之十二 NS-200危机
  13. Netscreen的岁月 之十三 ISG-2000
  14. Netscreen的岁月 之大结局 邓锋隐退
  15. Netscreen的岁月 后记

公司上市了，我们的生活还是没有什么变化。因为有6个月的禁售期，我们的股票都没有套现，大家还是老老实实地工作。只有Ting耐不住气，跑到宝马dealer那里买了辆M5，因为心急，现车只有一辆死红死红的猪肝色，也给买回来了。

最初的NS-100已经支撑了四年，虽然其中历经了NS-100+, NS-100P等静悄悄的硬件升级，性能已经比当初提高了不少，不过只有三个百兆端口，已经不能满足市场的需求了。

在这个背景下，设计一款全新的产品，提高竞争力已经是当务之急。公司新来的产品经理，Lee Klarich，具体负责这个产品。Lee很瘦削，不苟言笑，经常和我们这帮工程师争吵，一付美国愤青的样子。

当时项目多，硬件工程师也排不过来，因此还是由我来负责硬件设计。经过NS-1000项目，我对硬件的理解和掌握提高了很多。之前Neptune芯片一直用双端口SRAM，RAM的另一边接到系统控制芯片(Marvell)的Local bus上，所有的包都用DMA引擎传输到这片SRAM上。但是原本系统控制器的Local bus是用来连接启动ROM等低速芯片的，CPU存取这片空间存在性能瓶颈。

我的第一个设想是用CPLD来模拟DRAM接口，这样SRAM就可以直接接到DRAM总线上，不仅总线带宽由32位加宽到64位，而且支持同步burst模式，数据包的存取性能一下子提高了八倍。

第二个想法是充分利用两条独立的PCI总线，把8个MAC设备分别挂到两条总线上去，这样PCI的传输速度又提高了一倍。

老毛是个电脑爱好者，对台湾产的主板能够超频交口称赞，一直鼓捣我也在硬件上加入这个功能。我被他的喋喋不休给弄烦了，这次就依他所愿，也加入软件超频的功能。

板子设计非常成功，第一个版本就全部验证通过，而且FCC/UL测试都没有问题，直接可以投产。这是Netscreen历史上绝无仅有的一次。而且性能测试超出所有人的预料，NS-200用一个低端350MHz MIPS CPU，把NS-500的配有L2缓存的高端系统给干掉了。

我和老毛开始玩超频，发现把PCI的时钟从33MHz超频到37.5MHz，小包性能一下子从60Mbps升到100Mbps的线速，哥俩都非常得意。正准备拿出去测试忽悠一下，让另一个产品经理Gregory知道了，在公司里面大声嚷嚷说我们俩作假，只有Yuming的代码才能跑那么快。Gregory也是元老级员工，让他这么大嘴嚷嚷，结果这一“伟大”的功能无疾而终。

NS-200顺利投产，Lee根据两种不同的配置，分别命名为NS-204和NS-208。因为性价比较高，客户很快接受了这款产品，公司开始大量出货。

3个月后，不少客户发现在流量大的时候会突然出现不断的系统重启，可是测试部根本无法复现。情况开始变得比较紧急，Ting怀疑是硬件问题，邓锋决定派我去客户现场处理。

时间紧迫，客户是位于华盛顿特区的Verisign公司，我出发时已经是下午6点，转了一次机，等飞到Dulles机场，正好是当地时间早上7点。一分钟不能耽搁，销售过来接我到Verisign，他们刚刚上班。客户见到我很高兴，说终于等来了带示波器的家伙。在客户现场确实可以看到系统重启的过程，不过我还是一筹莫展。下午，Ting打来电话，说已经可以复现了。原来之前一直是用Smartbit灌流量，后来才想到用一个实际网络模拟软件Chariot很快就能复现。

我又急忙赶回去。已经两天一夜没合眼，困得要命，还好买到了直达航班的票，而且由于时差的缘故，下午6点的航班到旧金山是晚上8点。到了机场，没有回公司的车，打了个的，结果刚出机场计价器就跳个不停，到了San Mateo,  我心里实在承受不住了，要求司机找个路口下车。然后打电话让老葛过来接。夜里9点多了，老葛还没下班。他负责平台软件，因此和我是一条绳上的蚂蚱。到了公司，才知道之前不能复现还有一个原因，测试组用的是第一批生产的平台，而只有最近出厂的产品才有问题。

我把注意力都集中在两者的差别。最后还是我们的元器件工程师Alex，一个和蔼可亲的俄国佬，发现新批次的Marvell芯片是B3版本的，而最初的产品用的是B0版本的。

这就好办了，老葛把寄存器全部dump出来，我们一个个地对比。终于发现DRAM控制器的一个比特位有变化。原来这个寄存器大家都没动过，用的是原厂的初始值。没想到芯片版本更换之后，可恶的Marvell把那个宝贵的初始值改了，害死了我们。

找到问题，解决变得轻而易举。软件立即着手编译版本，一直忙到第二天凌晨。新的软件一发布，这个重大问题立马解决，总算有了个圆满的结局。

—————————- 版权所有 Hillstone 老童 欢迎转载 —————————-

系列前一篇 系列下一篇
(8个打分， 平均：4.75 / 5)

工具箱
本文链接 | | 打印此页 | 18条用户评论 »

雁过留声

“Netscreen的岁月 之十二 NS-200危机”有18个回复

  1. 理客 于 2011-10-06 5:14 下午

    用CPLD逻辑的方式做一些bus类控制，在2001年应该算比较早的，以及PCI的使用方式，童总对总线肯定非常精通，当时此类板子能一次投板成功，是很有功力的。
    硬件问题的复现过程，其实如果严格遵守相关的经验和流程，不应该这么慢，说明当时NS的测试部门能力可能不是很强
    也曾经到客户机房现场蹲点处理过每天重启问题，还好，有总部的一位问题定位高手一起配合，3天搞定，我本来预期正常时间是1周

  2. kevint 于 2011-10-06 9:29 下午

    这跟测试部门的流程没关系。

    在某司测试流程极度完备。这种寄存器一个bit的问题，没少出过。

  3. 理客 于 2011-10-07 12:09 上午

    一般的经验是复现条件和环境相似度是紧密相关的，不能复现，首先就是要检查环境的相似度和差异，这种差异什么都有可能，比如硬件芯片的版本，一般硬件单板要更换芯片版本或者更换同等芯片的不同厂家，在单板版本号或者序列号上是要有体现的，比这个问题更难的是芯片没变，只是不同的批次，都可能影响结果，最夸张的可能还和时间有关系，比如太阳黑子活动对单板硬件的影响；还有和地理位置相关的，如温度湿度海拔等，所以文章中的问题虽然不是最顶级的问题，但提供了很好案例。troubleshooting和doctor看病很像，能做到中西医结合是最好的方法
    曾经处理过的那个问题是和网上流量内容及时间积累有关，真正定位出那个问题的兄弟很牛，北大的，入过国家奥数选拔，那时我们常一起配合工作，他不喜ZZ，所以没有仕途
    大体上，只是要问题就能复现，能复现就能解决，做技术年头多一点的人，大多会有这种自信

  4. kevint 于 2011-10-07 12:24 上午

    这种1bit问题我搞过2次。一次2个星期，一次从找复现条件到最终定位历时三个月。每次都掉一层皮。初期找不到复现条件几度放弃，已经准备把责任扔给太阳黑子了。幸好不是在客户机放出的问题，不然就得掉一层肉了。

  5. 理客 于 2011-10-07 12:41 上午

    更深的看，文章中的问题还是管理问题，不是自己的管理问题，就是供应商的管理问题，因为管理流程缺陷造成的有些问题，经常很害人。
    现在问题定位的危机是在海量代码和芯片门数下，一些深层的问题是在海底的，大海捞针太难了，所以不从管理和架构设计上解决，就可能造成指数级人工查找，这个和刑侦的排查以及加密解密是类似的，有解但你可能无法在有限的时间内找到，也等于无解，前面提到吴总对H公司V8化繁为简的功力，对大型系统的架构师，极其重要，否则你个人再聪明，也跟不上系统复杂度的升级，何况大部分远不是fellow级别

  6. hoverdsp 于 2011-10-07 2:10 上午

    一般来说，芯片版本升级后应该会出一个Errata，不过对于已经走到批量生产的产品来说，可能最初的设计师可能不会去关注这个差别了。感觉如果对于物料代码的审核流程完毕的，就可以避免这种问题了。

  7. oioioioi 于 2011-10-07 2:36 上午

    楼上两位说是物料管理，纯粹是臆测，不要误导别人，做过的都知道芯片厂家的版本管理是厂家是大爷，你爱用不用，反正我升级了

  8. 老侯 于 2011-10-07 3:10 上午

    谁来解释一下为什么DRAM controller一个bit错误会导致流量大的时候设备重启？

  9. kevint 于 2011-10-07 11:24 上午

    DRAM不稳定的下场就是重启

  10. 理客 于 2011-10-07 12:43 下午

    一般来说，厂商对版本都是有相对标准的生命周期管理，并不是有很多随意终止和升级芯片的。
    下游供应商或者说乙方能否变身为甲方大爷，由其在上游供应商的地位决定，做大爷要有做大爷的本钱，否则是就是自慰

  11. mpc8240 于 2011-10-07 12:46 下午

    Isn’t this a device driver software bug? Device driver is always supposed to program all registers/bits based on config, regardless of their default value.
    Could be Marvell’s bug though, if the driver comes with chips.

  12. any 于 2011-10-07 9:44 下午

    强烈建议老童的《Netscreen的岁月》能出个PDF，我们放电脑里有时间好好读读，很有意思和意义。

  13. 水煮鱼 于 2011-10-07 10:03 下午

    这种问题定位的太多了，呵呵，还有内存问题，都是些很恼火的问题。一般也比较难想到，一般问题定位一个看悟性，还有一个就是经验。系统问题，一般都让人脱一层皮。

  14. 大黄蜂 于 2011-10-08 1:53 上午

    做研发感觉就是在磨练自己的心智，尤其这种软硬件搅在一起的bug。多碰到几个不是修炼成精，就是精神崩溃。

  15. zongbu 于 2011-10-08 5:26 下午

    童总的故事，就像一篇励志文章，对我起到了极大的鼓励和促进作用。至少当现在加班到12点时，还会想着，童总曾经的彻夜不眠，我这算什么？

  16. any 于 2011-10-08 10:11 下午

    看见首席占领华尔街

  17. CloudFS 于 2011-10-08 11:26 下午

    一直在跟读童总的这个NetScreen系列。真可谓亿往昔峥嵘岁月稠啊。可惜我晚几年毕业，没赶上跟各位老大一起闯闯江湖。
    小弟是清华2字班的（92入学），现在和朋友在做一个云计算里的文件系统的项目。核心技术是基于朋友开发的一个分布式文件系统。该系统曾获得几次Super Computing conference的奖。我们去年曾跟Menlo Park的几个VC谈过，总的感觉是对我们的技术都很感兴趣，但是觉得我们的团队有些单薄，缺乏管理和运营的经验。有点差临门一脚的感觉。想必童总一定知道NS当初找VC的艰辛。象我们这样工程师出身的老中在弯曲找VC还是不容易呀。不知道童总能否拨冗帮助我们引荐一下弯曲或者国内靠谱的VC。比如邓总的北极光。小弟感激不尽。

    不知道这个帖子童总能不能看到。如果陈首席能转发给童总一下，小弟非常感激。我的邮件是blogzen at gmail dot com

  18. Puppy 于 2011-10-24 6:36 下午

    Marvell的文档是烂得出了名的，从原则上说每个寄存器都应被设置，经常遇到datasheet中没有描述的寄存器，在厂商的sdk中被设置。更不用说Errta了。很多时候都是逼着厂商问才知道的。