免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1010 | 回复: 0

悖论下的最后期限ixp2400 [复制链接]

论坛徽章:
0
发表于 2006-06-19 13:13 |显示全部楼层

本文档的Copyleft归skipjack所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。
邮箱:
skipjack@163.com
来源:
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也没有问题、BA更没有问题。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上,看看还死锁不。”
   “还是你来泼吧,我知道你的茶叶比我的好。”
   待续……


本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/17060/showart_129845.html
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,8.5折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时8.5折扣期:2019年9月30日前


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

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP