悖论下的最后期限ixp2400

本文档的Copyleft归skipjack所有，使用GPL发布，可以自由拷贝，转载，转载时请保持文档的完整性，严禁用于任何商业用途。
邮箱: [email protected]
来源：http://skipjack.cublog.cn

    5天已经过去了，客户反映的IXP2400的bug竟然还没有准确定位。最具讽刺意义的是客户昨天突然出现在我工位前，亲自询问调试的进展情况。我只是一名普通的研发人员，说的直接点不过是一个coder而己，接客户的电话都是我份外之事，何况是接待一个心急如焚的客户...？？！！

    看看傍边的A君（微码开发人员），他已经熬了几个晚上了，也处在崩溃的边缘；又看了看我电脑上运行的emacs，这几天不同源代码版本之间的出库、入库、比对、排查。使Linux目录下的RCS目录增加了一倍，遍地都是以~n.n~为扩展名的源文件尸体；最后又瞄了瞄窗外，晕～一个美女也没有-_-!；我打算和客户摊牌，说说我们的处境。

    把客户引见到会议室，1、2、3、4，数了数一共4个。真希望他们冲上来捂我一顿，我就可以不去管什么IXP2400了，就可以躺在医院里好好的休息两天了。呜呜...“我们陷入悖论了”，终于还是我先开口了。悖论(paradox)来自希腊语“para+dokein”，意思是“多想一想”。 如果承认它是真的，经过一系列推导后又发现它是假的。

    Intel的IXP2400标准使用模式是4光口、4电口，防火墙可工作在路由、透明桥模式下，根据上层功能化分又可以实现VLAN，内容过滤，VPN。所以排列组合的工作方式就会有N*N*N种。我们只在一种排列下出现问题，而不是在一种组合下出现问题。说得再搞笑一点，就是A、B两口做桥，A->B没问题、B->A也没有问题、B<->A更没有问题。64字节小包都是双向线速的。但当我把AB口网线互换一下，问题就出现了。这能说明什么问题？（备注：我只是举一个类似的例子，因为真正的bug不是这样，解决方案现在也是公司的技术机密，所以我不能直接进行描述，对不起大家了，你们BS我好了） 联想了一下国内某NP厂商，他之所以失败，很有可能就是在这个环节上折损的，为什么这么说呢？因为如果说死机是十个因素共同作用的结果，则我接触到他的产品中就占了九个，如果他低层再用“哪种”实现方式的话，呵呵...十个因素就凑齐了，他今天的结局就不难预料了。这个问题，如今我们也遇到了，真不知道可不可以跨过去。硬件？驱动？微码？核心组件？Linux？那底是那里出了问题？会触发这么一个变态的悖论现象？

    把客户送走后，走到A君旁边告诉他：“咱从头再梳理一遍，最后确认是不是只有这一种功能排列会出现死锁，不排除硬件的问题，从硬件MAC的内、外环开始测起，把Intel工程师发过来的建议再仔细看一遍，确认导致死锁的第十个因素已经去掉了”。客户的电话紧跟着打了过来：“下周一，必须交付”。现在的时间是周四，我们只有不到4天的时间了。4天之后数十台NP防火墙可能就会被退回来。再之后就是二倍于前者数量的合同被取消。看了看公司人力资源部门给我发的邮件，公司希望和我再续签三年的劳动合同，但我只想续一年，反反复复拉距有近一个月了。再过2周我的合同也就到期了。现在已经想好了，如果这个bug解决不了，我就辞职，嗯...对不住已走的NP开发人员，更对不住我自己设计的NP防火墙连接状态同步的解决方案，有时候心累比身体累更容易压垮一个人。

   扒光我面前的一台IXP2400，去掉一个大的散热片，依照Intel工程师的建议找到了MAC控制芯片：ixf1104ce b0。它身上还有s417900Z e17001aq Canada等字样。Google了一下，什么有用信息都没有。加载诊断程序，内环、外环、xscale、mem……能测试的硬件从头测试一遍。无果…匀没有问题。狠狠的瞪了一点ixf1104ce，不甘心呀！因为死锁的第一个因素就是这颗芯片，我们用的是单NP版，而Intel的ixf1104ce的驱动是双NP版，Intel双NP版驱动我们加载不上去，因为我们的硬件上没有switch fabric interface。所以用了一个第三方驱动，这个驱动源文件从头查过了，没有问题，只是对硬件进行初始化，在程序运行过程中不干涉硬件行为。悖论的结果是，如果MAC层的ixf1104ce有问题，为什么其它的功能组合下收、发数据包会一切正常？

    微码的硬件调试设备很贵，要三十多万，我们没有。Sdk中虽然可以用软件进行运行时模拟进行调试，但对硬件线程的模拟总是和实现有所差别，微码远程调试时系统又必须做为NFS启动，也不方便。Kgdb的串口调试根本就不支持。呵呵…所以我们创造性的发明了“遗书”调试法，就是在Linux或微码临死之前把其最近的状态告诉对方。由对方把信息通过某种手段显示在我们面前。我们用这个方法摆平了不少问题，但这种方式也有不好的地方，一是Linux和微码两者不能同时死掉，二是所谓的信息可能就是dump一大块内存出来，看01代码真的很痛苦。还好，我们遇到的问题仅是微码死锁，而上层Linux运行的一切正常。

    “遗书，写好了。看看里面写了什么”，A君说道。（A君是清华的硕士，他前任的微码开发人员也是清华硕士，两个人都很厉害。）

    “看不出什么东西，一段内存里你好像写了三个四字节的长字，他们是什么？”

    “再查看一次”

    “他们在递增，没什么规律，嗯…第二个数比第一个数递增的慢大概三倍吧”

    “你确认？嗯…好的，现在给IXP2400注入流量，把哪些数据包发给它，每秒1000包，每发一送，换网线一次”

    “OK~，好的。开始了”。我操作着身边的ixia400测试仪，脚本把预定好的流量发送到对应网口。说实话IXIA400的噪声很大，平时我们都不愿意启动它，但它如今也连续运行5天了。摸摸它～我感觉我还不是太可怜。

    “不断的查看遗书，看看死锁后有什么不一样”

    “锁了，又锁了，第一个数在变，第二个数不动了，第三个数还在动”

    “收包模块没有问题，ixf1104芯片没事儿，你的怀疑是错误的。第一个计数是收包线程计数，第二个计数是包处理线程计数，我就说嘛，收包不可能有问题，我的微码根本就不知道下层是靠什么介质来获取数据包的。第二个计数不动了，说明是包处理线程死锁了。”，叹了口气的A君说道。

   “我的怀疑有问题？Intel的工程师怎么说的？如果相同的包处理程序在电口下没有问题，则在光口下也一定没有问题。我现在只要把光口改为电口模式，肯定就不会死锁了。我们已经在这里转了好几天的圈圈了。Ixia400都跑死过两次了，也没找到悖论的出口” ，说这话的时候我已经底气不足了，必竟计数器的结果放在这里。但我知道他悖不出去，所以说出来也好争回点面子。

   “电口比光口要多用一个芯片进行处理，除了要用到ixf1104ce芯片外还要用到cicada的那个芯片，多一个芯片处理程序都没事，少一个芯片反而会出问题”，A君说出了一个叫我抓狂的另一个悖论环节。

   “A君，你让微码自己转发数据包吧，把所有的防火墙功能都去掉，不把数据包上送到Linux处理，看看还死锁不。”

   “死啊…！前天咱们测试过了呀。”

   “A君，那你把所有的包都上传到Linux处理，所有的转发数据包，你都在异常队列中接收，然后再发送到微码的发包队列中，看看还死锁不。”

   “死啊…！这个功能不是你费了九牛二虎之力修改了核心组件的IPv4转发功能，才完成的吗。你今天零晨还在那里咆啸，说什么Intel的SDK是什么鬼东西，默认转发的数据包必须是IP包。害的你ARP转发时被修改的面目全非。”

   “A君，你把你的茶水泼在IXP2400上，看看还死锁不。”

   “还是你来泼吧，我知道你的茶叶比我的好。”

   待续……