205、意外死机TOM难堪,关键时刻X被点将（3/3）

　　......
　　第一天的OFC展会就在这样一个令人沮丧的气氛下结束了，回到宾馆，第一件事就是复制今天展会上遇到的问题，因为对软件产品的问题来说，只有能够复制的问题才能被解决，否则你既无从着手，也无从检查问题是否已经被解决了。
　　经过反复下载更新软件然后中途切断电源，最终发现大约每几十次的断电操作中就会有一次会变成“死机”，换句话说，今天展会上遇到的问题确实存在，而且确实与切断电源有关！
　　问题被复制出来了，但原因却不知道。
　　整体系统软件的结构是这样的：
　　一共分成两部分：
　　第一部分是启动程序，只负责光通信的启动和下载更新软件；
　　第二部分是光通信模块的控制和管理程序。
　　其中启动程序是固定不变的，出厂后是不允许更新的，更新的只是控制和管理程序。
　　下载更新软件时，下载下来的新程序被放在一个缓存中，等下载结束后，先校验下载下来的内容是否正确，如果不正确，则请求重新下载；如果正确，则再覆盖原来的程序进行更新，然后再次校验覆盖更新后的程序是否正确；如果正确，则重启光通信模块的软件系统。
　　这样的安排，从理论上讲，无论在下载的过程中发生什么问题，即使由于种种原因，导致下载更新失败了，也不会造成“死机”，但实际的情况是却出现了“死机”。
　　因此大家七嘴八舌地争论了起来，各种观点和推测都有，莫衷一是。
　　Tom见大家你一言他一语，都快晚上8点了，但还是没有找到问题的症结所在，于是就大声建议道：“大家先去吃饭吧，顺便冷却一下，吃完饭回来再说。”
　　大家听Tom这么说，就嘟嘟囔囔地一边说着自己的观点一边向外走去。
　　我没有跟随大家一起去吃饭，因为我嫌他们在的时候人多嘴杂，吵吵嚷嚷地让人听了心烦，他们走了，正合我的心意，因为这样我就可以冷静下来仔细考虑问题了。
　　我写了一个小程序，把“死机”后的光通信模块中的程序以ASCII码的形式读出来，和正常的光通信模块中的程序进行比较。
　　我发现，“死机”的光通信模块中的程序都乱了，这可以理解，但令我惊奇的是居然启动程序也乱了！
　　在整个光通信模块的软件系统中，是没有任何指令会把下载的程序内容写到存放启动程序的内存空间去的，但现在却意外地乱了，而且每次“死机”都会发现启动程序乱了。
　　我恍如大悟！
　　我相信我找到问题的症结了！
　　不管发生什么事，都要冷静、沉着——狄更斯。
　　【下章看点】
　　X找到了“死机”的原因，但怎么解决呢？
　　如果不解决这个问题，虽然X可以交差了——他答应那两个AT&T人第二天给他们答案，那么LunX的CWDM系统在OFC的首秀无疑就失败了！
　　因为去OFC参展也好，世界上第一款的CWDM系统的首秀也罢，都不是目的，目的是要把公司的产品向市场，而AT&T肯定不会看上这样有问题的产品的。如果真是这样的话，那LunX希望通过在OFC上推出世界上首款CWDM系统来推动公司的下一轮融资和未来的纳斯达克上市的计划也就告吹了......
　　欲知详情，请见下一章分解。