在自己没有管理多台高负荷的ubuntu显卡服务器之前，我是万万想不到linux服务器居然也是如此容易死机的。
什么每个版本的TensorFlow调用显卡驱动时和内核不兼容，什么系统自动升级导致的显卡驱动和内核不兼容，什么显卡驱动没有设置为persistent模式造成驱动进程启动超时，总之，管的时间长了这个GPU服务器啥样原因造成死机的都有，真是要人不得不感慨。
今天要记录的一次服务器死机的原因是显卡高负荷所引起的。
------------------------------------------
具体排查过程：
服务器死机后显示屏上的报错信息：
根据这个信息，我们知道服务器死机的同时报出大量的INFO：nmi handler took too long
NMI不可屏蔽中断的信息频频报出，说明此时存在某个CPU进程在调用内核函数时已经超时，由此造成系统内核soft locked，此时整个服务器已经进入slow down的状态了，这也是服务器死机的一种表现。
在服务器死机，NMI信息频发的同时，我们可以看到kernel记录了Call Trace信息，也就是死机时报错的内核函数的函数调用信息，该信息可以作为调试信息和检查死机原因之用。
根据Call Trace信息，我们可以知道造成服务器系统死机的具体进程的报错信息，因此可以知道native_queued_spin_lock_slowpath是造成这次死机最初的那个点的入口。
这个Call Trace信息需要从下往上看：
entry_SYSCALL_64_after_hwfram ：准备进入系统调用阶段
exc_page_fault ：访问缺页
do_syscall_64 : 进入系统调用阶段
x64_sys_ioctl : 内核对设备驱动程序中的I/O通道进行调用
nvidia_frontend_unlocked_ioctl : 内核空间下调用nvidia驱动的I/O通道函数
可以看到报错的信息主要是nvidia驱动在进行I/O操作时候引起的。
===============================================
由于我们的这个Dell服务器是可以通过远端管理的，我们通过远程管理界面看看厂家给的监控信息：
可以看到官方厂家给出的报错信息为：
A bus fatal error was detected on a component at slot 6.
A fatal error was detected on a component at bus 216 device 0 function 0.
根据这个信息，我们查看PCIE上的设备信息
可以看到6号槽的设备信息为：
根据设备的地址信息，我们查看下这个地址下的设备到底是什么设备：
可以看到这个报错的设备就是第四张显卡。
=================================
查看操作系统的内核日志：
可以看到在服务器死机的时候第四个显卡的电源模式转为最高，再根据最初的死机时报错的信息我们可以估计出问题是第四个显卡在满功率运行并且再进行内存和显存的申请、读取等操作，这时候内核陷入了死锁等待。
造成系统死机的直接导火索是第4个显卡运行满负荷，在进行I/O通道操作时造成了NMI的累计，最后形成了死锁，但是其根本原因则是内核与nvidia显卡驱动的不匹配问题。显卡满负荷只是诱因，直接导致这个发生的则是内核太新，驱动太旧：
=============================================