Linux 系统报错 rcu_preempt detected stalls on CPUs/tasks
作者：互联网
说在前面的一些废话：
这是什么错误我不知道，为什么出现我不知道！
那为什么还要把他写出来了，只是因为这个错误遇到了，而且浪费了我很多时间和精力。
故事留给自己看，解决办法就是，重新升级一下Linux系统内核。
这个问题出现在Reboot之后，不能进入不了系统，平均发生几率是40次左右出现一次。
之后重新升级完内核后没有出现。至于内核改了什么我也不知道。
Linux 系统报错如下：
故事：
去年用C语言写的软件，过年客户才真正用起来，结果接二连三的出现死机的问题.
怀疑是自己的程序写的有问题，开始各种尝试，自己也做各种耐久验证，跑了半个月都没有发现问题。
对于这些问题，也问了工控机的厂商，他们说是环境会有影响。
然后是我们的各种验证，还好现场还有两个正常运行的机器，
基于小白的基本验证法则（对Linux系统仅限于简单命令的操作）：
1.我们把正常的和异常的机器进行交换，结果3天都没事.
2.把我们验证好的盒子寄给现场，进行更换。结果2个小时就挂了。
这是什么结论？？？
还要就在我们要飞到现场的时候，现场把更换下来盒子寄给了我们。
不管Linux的专业知识水平怎么样，硬着头皮上吧！
就连同事也觉得可能验证不出来什么东西。
刚开始验证风平浪静，十几次种操作的验证，全都很正常，我也要放弃了，就像舌尖上的中国说的，“剩下的就交给时间了”。
一次不甘心的重启后，异常再现了。这时感觉好像，everything is contorl~~~很是兴奋！
这就是厂商的问题了，我很幸运，再十几次的就出了这个异常，因为再后面的验证中，反复重启100次才出了这个异常。
其实这并不是什么高深的技术，我也不清楚内核里面到底改了什么，这个问题的发生机制是什么，
也没有资格说厂商太不专业（因为我只是找到问题的人，最后解决问题的还是人家）？
只是记录一下，这件事带来的感触。
1.面对别人的质疑---只能先自我怀疑，再自我肯定
动不动别人就是说程序写的有问题，但没有找到其他原因，你又不能说没问题，只能一遍一遍的检查程序，偶尔想到什么就赶快改上去验证。
其实就是别人不说，我也在问自己到底那里的问题，只是一听别人这么说我就有点火。
但是真的很幸运现场有两台设备由于不是一批购买的，始终没有出现问题，慢慢的我对程序还是有信心了。
2.好的点子，都是慢慢熬出来的
那时候对自己也没有信心，不愿想这件事，但是每天都要面对，现场说又坏了，虽然别人不要你赔偿什么但总是感觉好像亏欠别人什么。
自己技术能力有限出现这个匪夷所思的问题，真的有种束手无策的感觉。这能从简单的验证下手，没想到解决了。
当然这些想法不是凭空出现的，对于我这种想了10来天才出现。
3.什么才是真正的技术---真正的技术是没有尽头的探究，但现实的问题可能没有那么复杂。
我这种三线程序的小程序员，只是技术上的搬运工，把别人现成的东西直接用。有些地方可能都没看懂，速成式的学习，一知半解的应用。
但是在现场真的不是那么轻松了，出问题就要解决。你要对一知半解付出代价的！
不过别慌，基本的逻辑法则还是通用的，简单的说：交换，再现，交给时间！
扩展来说：
交换排插原因，进行再现问题的各种模拟，如果短时间什么都不行只要别放弃，把问题交给时间肯定一天答案会出现再你面前！
对自己的程序需要不停的完善他，问自己那里还能做的更好！
标签：tasks,验证,现场,rcu,什么,问题,报错,内核,Linux 来源： https://www.cnblogs.com/ccsharppython/p/10746373.html