一个难找的BUG

<1>

 

     写了个通过/dev/mtd设备读写flash params区的函数。运行重启后，flash params参数区自动复原。结果第三次重试的时候，内核挂掉了，死在uncompressing...............................boot kernel.这里。

     

      以为是公司提供的加密内核在3次flash参数被破坏后自动锁死呢（有点像银行密码输入验证一样）。重新升级程序和编译非加密内核都不行。当时也是没多懂脑子，以为params区藏了好多加密信息。所以只好重新扫写flash了。

    

      后来偶然发现是uboot bootargs参数写错了。原因是我把长长的bootargs参数复制到ms notepad里面了。而notepad自动截断bootargs后，在中间添加了换行字符。导致通过串口发送的uboot bootargs参数中间多了个字符。所以参数错误导致kernel启动不了。

     

      后来想想，这BUG的难找的原因是，对公司params区的内容不了解，因为没有文档。以为有加密信息。其次FLASH扫写params后重启失败的。所以一直把精力放在params参数上，以为是该区域加密数据被破坏。所以导致的内核挂掉。

      虽然多次审查uboot启动参数准确无误。但是忘了一些软件自动添加的控制字符。所以导致耽误了1天的时间。

 

  

P.S. 把内核启动复制到notepad中，然后通过串口发送到uboot上。本来是为了节省时间的。谁知道惹来这么大麻烦。而且正好是我在调试flash读写函数的过程中。。。。悲剧。。。。

 

 

<2>系统被线程宕掉的原因。

 

开了一个线程，结果系统就陷入死循环了。找了半天，有些人把线程优先级设的太高了，导致别的线程无法抢占。

     

为了既能快速响应终端程序

又要运行大量消耗CPU的程序

 

只能给终端程序高优先级，消耗CPU的程序低优先级---这也是一般桌面系统进程调度策略的设计原则。