说在前面的一些废话:

这是什么错误我不知道,为什么出现我不知道!

那为什么还要把他写出来了,只是因为这个错误遇到了,而且浪费了我很多时间和精力。

故事留给自己看,解决办法就是,重新升级一下Linux系统内核。

这个问题出现在Reboot之后,不能进入不了系统,平均发生几率是40次左右出现一次。

之后重新升级完内核后没有出现。至于内核改了什么我也不知道。

Linux 系统报错如下:

rcu_preempt detected stalls rcu_preempt detected stalls on_x系统

 

故事:

去年用C语言写的软件,过年客户才真正用起来,结果接二连三的出现死机的问题.

怀疑是自己的程序写的有问题,开始各种尝试,自己也做各种耐久验证,跑了半个月都没有发现问题。

对于这些问题,也问了工控机的厂商,他们说是环境会有影响。

然后是我们的各种验证,还好现场还有两个正常运行的机器,

基于小白的基本验证法则(对Linux系统仅限于简单命令的操作):

1.我们把正常的和异常的机器进行交换,结果3天都没事.

2.把我们验证好的盒子寄给现场,进行更换。结果2个小时就挂了。

这是什么结论???

还要就在我们要飞到现场的时候,现场把更换下来盒子寄给了我们。

不管Linux的专业知识水平怎么样,硬着头皮上吧!

就连同事也觉得可能验证不出来什么东西。

刚开始验证风平浪静,十几次种操作的验证,全都很正常,我也要放弃了,就像舌尖上的中国说的,“剩下的就交给时间了”。

一次不甘心的重启后,异常再现了。这时感觉好像,everything is contorl~~~很是兴奋!

这就是厂商的问题了,我很幸运,再十几次的就出了这个异常,因为再后面的验证中,反复重启100次才出了这个异常。

其实这并不是什么高深的技术,我也不清楚内核里面到底改了什么,这个问题的发生机制是什么,

也没有资格说厂商太不专业(因为我只是找到问题的人,最后解决问题的还是人家)?

只是记录一下,这件事带来的感触。

1.面对别人的质疑---只能先自我怀疑,再自我肯定

动不动别人就是说程序写的有问题,但没有找到其他原因,你又不能说没问题,只能一遍一遍的检查程序,偶尔想到什么就赶快改上去验证。

其实就是别人不说,我也在问自己到底那里的问题,只是一听别人这么说我就有点火。

但是真的很幸运现场有两台设备由于不是一批购买的,始终没有出现问题,慢慢的我对程序还是有信心了。

2.好的点子,都是慢慢熬出来的

那时候对自己也没有信心,不愿想这件事,但是每天都要面对,现场说又坏了,虽然别人不要你赔偿什么但总是感觉好像亏欠别人什么。

自己技术能力有限出现这个匪夷所思的问题,真的有种束手无策的感觉。这能从简单的验证下手,没想到解决了。

当然这些想法不是凭空出现的,对于我这种想了10来天才出现。

3.什么才是真正的技术---真正的技术是没有尽头的探究,但现实的问题可能没有那么复杂。

我这种三线程序的小程序员,只是技术上的搬运工,把别人现成的东西直接用。有些地方可能都没看懂,速成式的学习,一知半解的应用。

但是在现场真的不是那么轻松了,出问题就要解决。你要对一知半解付出代价的!

不过别慌,基本的逻辑法则还是通用的,简单的说:交换,再现,交给时间!

扩展来说:

交换排插原因,进行再现问题的各种模拟,如果短时间什么都不行只要别放弃,把问题交给时间肯定一天答案会出现再你面前!

对自己的程序需要不停的完善他,问自己那里还能做的更好!