低温故障处理

   这段时间定位一个路由器在低温环境下(-30℃)的故障（自称”北极故障 ^_^“ ）。 ­

   一直没有什么进展。最让我头疼的是，从第一天到现在，故障的现象都不相同。虽然找到了一些线索，但是更多的是迷茫。到目前为止，我所能做的解释就是路由器在这种环境下：硬件不稳定。因为在正常的情况下，运行是正常的。除非软件也会感冒，否则，这证明了软件是正常的。 ­

   平时由于对于稳定的熟悉，渐渐忘记了它的存在。这一次让我看到了，稳定是重要的。软件的完善建立在稳定的硬件基础上。否则，再完美的算法，都会出现各种各样的意想不到的问题。 ­

   达到稳定是需要一定条件的，例如，这次的条件：温度。 ­

   当常规的定位方法不奏效的时候，我们要自己创造一些可测试的手段，这是在以前定位一个故障的时候，钟师父教给我的宝贵经验。 ­

   故障定位的一个基本方法就是缩小怀疑的范围。对怀疑的部分进行替换，如果替换之后现象正常，那么被替换的部分肯定是出问题了。（困了? 下面就可以不看了。） ­

   从目前的情况来看，protocal进程挂起之后，平台和驱动应该不会去修改arp表项。那么剩下的就只是微码了。sram读操作在低温的环境下是否会引起其中内容的修改？ ­

   关于这个疑问，我想可以使用下面的方法来验证。在正常工作一段时间之后，触发一个设计好的开关，该开关打开之后，报文不需要读取sram中的arp表，而是自己根据ip和入端口来封装固定的mac地址。如果经过一段时间之后，sram中的arp表没有被修改，那么就肯定是微码sram读操作对arp表进行修改了。 ­

   这个故障到现在终于有一个结论了。正是通过上述的方法，经过实验验证之后，确实是sram读操作导致了arp表的修改。经过硬件人员进一步的定位，发现是QDR中一个电容焊接错误导致在低温环境下造成掉电的情况。 ­

   我很想说这次的故障是自己一个人搞定的。哈，多么骄傲。可惜，不是。这不是客套，而是千真万确的事实。甚至可以说在每一个关键地方的进步都产生于和别人讨论之后。星星和我一同去查故障，让我注意meta值，并思考微码挂起的原因。那天差点弄得不仅路由器出了故障，连人也快出故障了。异曲同工的头晕。^_^。在和可人的讨论中，我们找到了arp表项被修改了。师父提醒我排除平台和驱动问题的方法，和胡哥的讨论中，启发了我们最终怀疑到微码sram的操作指令上。在我们软件定位基本完成之后，最终是硬件人员的继续跟踪才找到了故障的根本原因。其中的辛苦我虽然不清楚，但是肯定不轻松。敢情在这个故障中，原来我什么都没干啊。。。 ­

   以前老边说：“每天花6个小时在学习上，花2个小时在和别人讨论上，比你花8个小时在学习上，效率要高得多。”。今天看来，老边的确是高人。 ­

   至此"北极故障"暂告一段落。北极熊离开了家乡，又踏上了旅途...­