一、机器信息
CPU：FT S2500
核心数：128
NUMA数量：16
RAM：512G
二、日志信息分析
从日志来看，在Jul 20 23:28:05分时，cpu 13检测到116号cpu超出了1个rcu的GP宽限期没有进入静止态Quiescent state。稍后13号cpu发送NMI中断给116号cpu，cpu之间通信通过IPI接口。
在间隔1分钟之后，接连出现了softlock异常输出， 检测到91号cpu发生了调度超时（22s为默认超时时间），如果超过22s cpu没有发生调度切换，则该cpu上的时钟计数无法更新，从而判定该cpu上发生了软死锁（在不可抢占cpu上，即没有主动让渡cpu，发生调度切换）
从堆栈输出来的调用看，发生软锁的位置在smp_call_function_single+0xa8的位置，
int smp_call_function_single(int cpu, smp_call_func_t func, void
*info, int wait) { …
this_cpu = get_cpu(); //关闭抢占 …
csd = &csd_stack;
if (!wait) {
csd = this_cpu_ptr(&csd_data);
csd_lock(csd);
}
err = generic_exec_single(cpu, csd, func, info);—阻塞在该函数内部
if (wait)
csd_lock_wait(csd); //循环等待
put_cpu(); //打开抢占
return err; }
此函数是用来将进程放到指定的cpu上运行，get_cpu函数会关闭抢占，put_cpu会打开。
generic_exec_single函数最终调用smp_call_function_single，该函数通过cpu之间的访问接口IPI，通知指定的cpu运行一个function,即执行一个动作。这里可以看出，smp_call没有返回，被阻塞住，超过了22s时间，该cpu没有发生调度切换。
arm上 使用寄存器传参，X3寄存器存储第四个参数值，即wait的值等于1，调用csd_lock_wait进行阻塞等待。 X1寄存器存储第一个参数值，即期望的cpu是0x74,即116号cpu。
总结就是，91号cpu期望116号cpu执行一个动作，但超时没有得到响应。
在之后的日志，记录得到进程node_exporter，进程号13946 进入D状态，超过120s时间，D状态为不接受信号的等待状态，等待资源满足才能继续执行，node_exporter经过检索为Prometheus监控服务器，用来监控服务器状态的进程，从堆栈看，在读取传感器sensors的温度信息，但看不出，这两个进程处于哪个cpu上运行。
可以看出，共有2个进程，分别是13946和13291,都是在获取温度信息，13291因为无法获取到互斥锁，而进入了等待。
在接下来的日志中，11号cpu检测到116号cpu，有1个GP落后，发送了NMI中断给116号cpu。
91号cpu上，发送给116号cpu的任务，依旧没有及时响应（超过23s），出现soft lock提示。
三、软死锁和rcu超时原理说明
linux在每个cpu上都会运行检测软锁的watchdog线程，如果内核线程关闭抢占后一直占用cpu到达设定的超时时间，那么就会报softlockup。一般触发软锁的情况，基本上是使用了自旋锁等关闭抢占的临界保护机制，循环等待申请的资源释放，一直占用CPU资源，最终超出watchdog设置的超时时间，导致软锁报警。
rcu_sched的检测分三种情况：
在RCU读操作的临界区cpu上循环运行程序
在禁用中断的情况下循环运行
在中断下半部禁用的情况下循环运行
四、初步结论
从当前获取的现有日志来看，rcu超时和soft lock超时，共同指向的cpu是116号cpu，基于日志无法获取当时，116号cpu正在处理的任务情况，无关判断导致116号cpu出现异常的原因。其中有node_exporter的2个进程长时间处于UN状态（D状态），猜测可能其中1个进程位于116号cpu之上，但无法证实。
机器从2月28日启动机器，到7.20发生软锁，7.21早晨手动重启，运行接近6个月时间内，未发现其他异常。基于现有日志尚无法判断出现异常的原因，但都指向了116号cpu,和116号cpu上运行的进程有很大的关系。可能是在运行某个代码时出现了死循环，且位于不可抢占cpu的环境，从而导致了异常发生。
该问题因机器bios固件没有加软锁补丁，先检查固件是否加入了软锁补丁，如果没有加可以联系bios厂商提供。