1.线上内核bug日志

lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。

watchdog能够看见，进程名称大概是watchdog/X（数字：cpu逻辑编号1/2/3/4之类的）。这个进程或者线程每一秒钟运行一次，否则会睡眠和待机。这个进程运行会收集每一个cpu运行时使用数据的时间并且存放到属于每个cpu自己的内核数据结构。在内核中有很多特定的中断函数。这些中断函数会调用soft lockup计数，他会使用当前的时间戳与特定（对应的）cpu的内核数据结构中保存的时间对比，如果发现当前的时间戳比对应cpu保存的时间大于设定的阀值，他就假设监测进程或看门狗线程在一个相当可观的时间还没有执。Cpu软锁为什么会产生，是怎么产生的？如果linux内核是经过精心设计安排的CPU调度访问，那么怎么会产生cpu软死锁？那么只能说由于用户开发的或者第三方软件引入，看我们服务器内核panic的原因就是qmgr进程引起。因为每一个无限的循环都会一直有一个cpu的执行流程（qmgr进程示一个后台邮件的消息队列服务进程），并且拥有一定的优先级。Cpu调度器调度一个驱动程序来运行，如果这个驱动程序有问题并且没有被检测到，那么这个驱动程序将会暂用cpu的很长时间。根据前面的描述，看门狗进程会抓住（catch）这一点并且抛出一个软死锁（soft lockup）错误。软死锁会挂起cpu使你的系统不可用。

3.根据linux内核源码分析错误

首先根据我们的centos版本安装相应的linux内核源码，具体步骤如下：

下面开始真正的根据内核bug日志分析源码：

（1）第一阶段内核错误日志分析（时间在Dec 4 14:03:34这个阶段的日志输出代码分析，其实这部分代码不会导致cpu软死锁，主要是第二阶段错误日志显示导致cpu软死锁）

这个宏很简单保证传递进来的条件值为0或者1（两次逻辑非操作的结果），然后使用分支预测技术（保证执行概率大的分支紧邻上面的指令）判断是否需要调用__WARN()宏定义。如果满足条件执行了__WARN()宏定义也接着执行一条空指令;。上面调用WARN_ON宏是传递的1，所以会执行__WARN()。下面继续看一下__WARN()宏定义如下：

从接下来的call trace信息中我们也确实发现调用了warn_slowpath_null这个函数。通过在linux内核源代码中搜索这个函数的实现，发现在panic.c（内核恐慌时的相关功能实现）中实现如下：

分析这个函数的实现不难发现我们的很多日志信息从这里开始输出，包括打印一些系统信息，就不继续深入分析了（请看代码注释，里面调用相关函数打印对应信息，通过我分析这些函数的实现和我们的日志信息完全能够对应，其中dump_stack是与cpu体系结构相关的，我们的服务器应该是属于x86体系）。这里在继续分析一下dump_stack函数的实现，因为这个是与cpu体系结构相关的，而且这个函数直接反应出导致内核panic的相关进程。这个函数实现如下：

这个函数打印出我们日志中的Call Trace信息，然后继续调用dump_trace函数（x86-64相关的体系结构，也就是64位的，还有一个32位的相应实现），如下：

通过这个函数的注释我们可以清楚的知道这个函数打印很多信息，包括进程堆栈信息、中断堆栈信息以及一些服务异常的硬件堆栈信息（如双重故障，NMI，堆栈错误，调试，MCE）。

通过上面这些分析只想说明一点，整个流程是没有问题的。到目前为止只有第一行日志信息还没有找到输出的地址，其实看源码很容易就看出来了，就在WARN_ON宏的上一行代码就是了，代码如下：

Printk函数的作用相当于printf，只是这个是专门用于内核的（有一些特殊实现）。通过一句代码我们也可以发现local_clock_stable是为0，因为没有打印最后那一点信息出来。到这里为止基本把第一阶段出现内核错误和bug的代码全部理解清楚了（日志时间为：Dec 4 14:03:34这个时间输出的），后面附件具体分析导致这个原因代码的原因。

（2）第二阶段（时间在Dec 4 14:03:41，与第一阶段只相差了几秒钟，应该还是存在一定的关联）内核错误日志输出代码分析，这部分日志输出显示了导致了cpu软死锁。

下面首先需要分析一下什么情况下会调用这个函数并且导致cpu软死锁，根据第二部分cpu软死锁产生原因的分析，每一个cpu都会启动一个对应的watchdog线程来监控cpu的执行状态，创建watchdog线程是在使能watchdog功能的时候，在函数watchdog_enable里面实现，代码如下：

从上面这个watchdog使能函数可以看出，每一个cpu的watchdog监控线程的入口函数是watchdog函数，还注册了一个softlockup软死锁响应函数。下面开始从watchdog函数继续开始分析，代码如下：

这个函数首先设置watchdog线程的cpu的调度策略为FIFO（先来先服务），并且优先级最低，然后初始化一个时间戳，设置当前的cpu状态为可中断的状态。然后就进入while循环了，通过while循环上面的注释我们可以清楚的知道每一秒钟都会重新设置softlockup的时间戳，如果超过60秒钟那么就会触发debug信息被打印，打印信息是在函数watchdog_timer_fn里面，这个函数是在watchdog模块初始化的时候注册的，每一个模块加载最先执行的都是模块初始化函数，当然卸载模块的时候也有相应的资源清理函数。

到这里为止我们知道了如果要打印出我们服务器内核的错误信息就必须得满足一个条件，就是已经超过60秒钟没有重新设置softlockup的时间戳了（每一，秒钟重新设置softlockup的时间戳，有一个比较通俗的说法叫做喂狗，因为上面的watchdog程序也俗称看门狗程序，cpu就是通过这种方式来检测cpu是否运行正常的，已经超过60秒钟没有喂狗了，那么狗肯定饿了，也就是cpu处于饥饿状态，浪费了cpu的时间了，最大的可能就是cpu产生了软死锁）。这里就不详细分析cpu调度相关的功能了，还是继续分析产生这种bug的原因。下面最主要的就是分析为什么超过60秒钟没有喂狗（重新设置softlockup时间戳）了。分析这个应该需要结合第一阶段的错误日志分析，第一阶段也是由于计算时间差值大于了一个设定的时间。

         上面我们已经分析到了函数watchdog_timer_fn打印debug信息的地方了，这个函数的在前面已经粘贴出来了，我们结合我们的错误日志分析一下对应的输出内核，通过函数的分析下面这句代码就是打印我们第二阶段错误日志信息的第一条：

而输出这一条的条件就是linux内核检测出了已经存在软死锁（通过前面if条件判断的代码以及前面的代码注释都可以说明这一点），通过这条日志信息我们可以看到cpu的逻辑编号、进程名称和进程id（通过我们的日志信息可以看出分别是11、qmgr进程、进程id是5492）。我们在看看一个更重要的值，这个值就是决定了是否产生了软死锁，这个值就是duration，这里显示是秒。下面详细分析一下这个值是怎么被计算出来的，通过代码发现是通过下面这个函数计算出来的：

30LL;这句代码计算出来的）。接着通过调用time_after函数判断现在的时间戳now与上一次喂狗的时间戳加上softlockup_thresh（60）的先后关系，也就是判断是不是有超过60秒钟没有喂狗了，如果是就会返回一个现在的时间戳减去上一次喂狗的时间戳，如果没有就会返回0。根据我们的日志信息，很明显已经超过了，所以返回值不为0，就导致了软死锁被检测到。

后面接着打印了linux内核加载了的相关模块信息，然后打印中断trace的事件信息，一直跟踪下去，发现和我们打印的内核bug信息完全符合。

下面开始分析一下call trace，不管是第一阶段的日志还是第二阶段的日志堆栈最上层的函数都是tracesys，说明这些信息都是在trace子系统中发生的，至少说明当时都处于trace子系统的运行。其实tracesys是用汇编实现的，主要用于跟踪系统调用的功能。第二阶段的call trace基本是没有什么信息，分析不出什么效果。有一点需要说明一下，第一阶段的日志打印的信息显示是master进程，第二阶段显示是qmgr进程。在centos上master进程是qmgr进程的父进程。下面看第一阶段日志的call trace信息，如下（去掉了公共前缀信息）：

我们首先看一下这个函数的参数：其中有两个比较复杂和重要的结构体ring_buffer_per_cpu和ring_buffer，分析这两个结构体主要是为了后面的函数内部分析做一个准备。我们先看看ring_buffer结构体（简称为RB结构体）的定义，如下：

在RB的操作中,我们可以禁止全局的RB操作，例如，完全禁用掉Trace功能后，整个RB都是不允许再操做的，这时，就可以将原子变量record_disabled 加1。相反的，如果启用的话,将其减1即可。只有当record_disabled的值等于0时，才允许操作RB。

同时，有些时候,要对RB的一些数据进行更新，比如，我要重新设置一下RB的缓存区大小，这都需要串行操作，因此，在ring_buffer结构中有mutex成员，用来避免这些更改RB的操作的竞争。

我们也可以看到，每个cpu都有一系列的页面，这样页面都链入在pages中。

具体的缓存区是由structbuffer_data_page指向的,实际上,它是具体页面的管理头部,结构如下:

把所有基本的结构体解析清楚以后我们就可以正在分析这个函数了，代码已经在前面写出来了。函数里面首先定义了一个ring_buffer_event结构体的变量，先看一下这个结构体的定义如下：

这个结构体注释提醒不要直接使用，只能在函数体里面使用，这里是在函数体里面定义和使用的。里面加入了动态内存检测的字段kmemcheck，这个特性类似用户态动态内存检测工具valgrind，只是实现上有很大的区别，而且这个主要是用于内核动态内存检测技术。继续上面函数的分析，然后定义了一些需要用到的变量。继续就开始调用函数rb_start_commit，函数代码如下：

其实最终就是使用汇编实现一个长整型变量的原子加（addl）1操作。接下来是一段需要使能了RB交换swap功能（和虚拟内存交换，linux系统称为交换区，有硬盘充当）。接下来调用函数rb_calculate_event_length计算事件长度。继续我们就会看到一大段英文注释，大体上是说，在调用这个函数之前禁止了抢占，中断和NMI在这里存在着竞争，因此在下面的运行中,随时都会被中断/NMI所抢占。由于在从struct ring_buffer_per_cpu中取页面的时候，会有当前页面空间不足，需要前进一个页面的情况.每次前进一个页面都会跳转到again，此时nr_loops都会增加1，如果在一次请求中,这样的情况出现了1000次，说明中断抢占的次数太多了，很可能是由于中断风暴(interrupte trace信息，根据我们的服务器日志这里没有打印。继续就是调用函数ring_buffer_time_stamp取当前的时间戳并赋值给ts临时变量。下面又是一大段英文注释，意思是只有第一次处于提交状态的请求才能够更新cpu_buffer->write_stamp（cpu的写时间戳），这里存在着竞争。下面详细分析这里代码执行的情况，因为涉及到delta计算的问题，这也是导致我们服务器bug的最基本和开始的原因。

从这里的if判断可以看到，只有在fistcommit的时候才会计算delta，其它的情况下，会获取下一个event。我们来思考一下，为什么在确认了是fist commit，进入到了if，还需要进行:

的判断呢？ 这个delta到底是用来做什么的呢?它为什么要用这样的判断方式呢？我们在之前说过，在ring_buffer_per_cpu中的每一块数据都带有一个event的头部，即:

它里面有一个time_delta的成员占27位。在每一个页面的头部，即Structbuffer_data_page里面也有一个时间戳，即：

那这几个时间戳有什么样的关联呢？在ring_buffer_per_cpu中有一个timestamp，它表示最近commit时的时间戳。每次切换进一个新页面时，该页面对应的：

综上所述,存在以下关系：

页面中的第一个event，event1在进行写操作时的时间戳为：

第二个event,event2在进行写操作时的时间戳为：

分析到这里我们发现计算出来的delta值超过了设定的阀值，所以打印处理debug信息，我们分析一下打印出来的几个时间值（应该是系统节拍值），日志如下：

cpu_buffer->write_stamp;通过计算器计算确实满足。那下面在看看ts是怎么计算出来的，他是计算linux服务器冲启动到现在的节拍数，和设置的HZ有关系，最终还是调用sched_clock函数计算所得，这个函数代码实现如下：

以上函数是cpu调度的节拍数计算方式，全局变量jiffies用来记录从系统启动以来产生的节拍的总数，启动时，内核将该变量初始化为INITIAL_JIFFIES，网上有的说法又是初始化为0，为了验证到底初始化为多少我们使用一个内核模块在启动的时候就把这个值打印出来看一看就清楚，通过测试初始化值确实是INITIAL_JIFFIES。此后，每次时钟中断处理程序都会增加该变量的值。一秒内时钟中断的次数等于HZ，所以jiffies一秒内增加的值也就是HZ。系统运行时间以秒为单位，等于jiffies/HZ。注意，jiffies类型为无符号长整型(unsigned long)，其他任何类型存放它都不正确。将以秒为单位的时间转化为jiffies：seconds * Hz。将jiffies转化为以秒为单位的时间：jiffies / HZ。HZ的值在param.h中设置为100，那么通过日志中打印出来的ts值（单位是纳秒）计算服务器已经启动了多少天：/60/60=213504（天），这个值明显不对，那我们在计算一下上一次cpu记录的写入值（write stamp = 46377）是否正确？同样的计算方式如下：/60=208（天）这个值还算比较正确，就是上一次写入对应的值已经是208天以前的时候。

SEC_PER_SEC是每一秒钟的纳秒数（）。

于是整个表达式计算为：系统当前运行的节拍值（INITIAL_JIFFIES计算所得），然后再除以/100=。从我们的日志中可以看出当前计算出来的值是ts：。根据这个值我们可以反推出jiffies-INITIAL_JIFFIES=2。这个值明显不对，在看cpu软死锁产生的一条日志信息如下：

通过这条日子好也可以看出这个时间s完全不正常。造成这种不正常的原因可能是内存破坏造成的。

新发现：在使用内核模块修改jiffies值的时候，直接导致了centos产生了cpu softlockup错误，而且从内核打印出的错误信息可以看出最后加载的模块就是我写的那个测试模块，对比线上服务器崩溃的内核日志查看最后加载的内核模块是scsi_scan_wait。由此可以推断可能是由于scsi_scan_wait这个内核模块导致了qmgr进程产生了cpu软死锁，也就是导致了qmgr已经超过了60秒没有得到中断响应了。

         由于一直不能重现这个错误，所以一直没有排查出问题的正在原因，目前还是继续排查，想办法还原错误。如果有哪位以前遇到过同样的问题并且得到了解决麻烦告知一声，非常感谢！

1.线上内核bug日志

watchdog能够看见，进程名称大概是watchdog/X（数字：cpu逻辑编号1/2/3/4之类的）。这个进程或者线程每一秒钟运行一次，否则会睡眠和待机。这个进程运行会收集每一个cpu运行时使用数据的时间并且存放到属于每个cpu自己的内核数据结构。在内核中有很多特定的中断函数。这些中断函数会调用soft lockup计数，他会使用当前的时间戳与特定（对应的）cpu的内核数据结构中保存的时间对比，如果发现当前的时间戳比对应cpu保存的时间大于设定的阀值，他就假设监测进程或看门狗线程在一个相当可观的时间还没有执。Cpu软锁为什么会产生，是怎么产生的？如果linux内核是经过精心设计安排的CPU调度访问，那么怎么会产生cpu软死锁？那么只能说由于用户开发的或者第三方软件引入，看我们服务器内核panic的原因就是qmgr进程引起。因为每一个无限的循环都会一直有一个cpu的执行流程（qmgr进程示一个后台邮件的消息队列服务进程），并且拥有一定的优先级。Cpu调度器调度一个驱动程序来运行，如果这个驱动程序有问题并且没有被检测到，那么这个驱动程序将会暂用cpu的很长时间。根据前面的描述，看门狗进程会抓住（catch）这一点并且抛出一个软死锁（soft lockup）错误。软死锁会挂起cpu使你的系统不可用。

3.根据linux内核源码分析错误

首先根据我们的centos版本安装相应的linux内核源码，具体步骤如下：

下面开始真正的根据内核bug日志分析源码：

（1）第一阶段内核错误日志分析（时间在Dec 4 14:03:34这个阶段的日志输出代码分析，其实这部分代码不会导致cpu软死锁，主要是第二阶段错误日志显示导致cpu软死锁）

这个宏很简单保证传递进来的条件值为0或者1（两次逻辑非操作的结果），然后使用分支预测技术（保证执行概率大的分支紧邻上面的指令）判断是否需要调用__WARN()宏定义。如果满足条件执行了__WARN()宏定义也接着执行一条空指令;。上面调用WARN_ON宏是传递的1，所以会执行__WARN()。下面继续看一下__WARN()宏定义如下：

从接下来的call trace信息中我们也确实发现调用了warn_slowpath_null这个函数。通过在linux内核源代码中搜索这个函数的实现，发现在panic.c（内核恐慌时的相关功能实现）中实现如下：

分析这个函数的实现不难发现我们的很多日志信息从这里开始输出，包括打印一些系统信息，就不继续深入分析了（请看代码注释，里面调用相关函数打印对应信息，通过我分析这些函数的实现和我们的日志信息完全能够对应，其中dump_stack是与cpu体系结构相关的，我们的服务器应该是属于x86体系）。这里在继续分析一下dump_stack函数的实现，因为这个是与cpu体系结构相关的，而且这个函数直接反应出导致内核panic的相关进程。这个函数实现如下：

这个函数打印出我们日志中的Call Trace信息，然后继续调用dump_trace函数（x86-64相关的体系结构，也就是64位的，还有一个32位的相应实现），如下：

通过这个函数的注释我们可以清楚的知道这个函数打印很多信息，包括进程堆栈信息、中断堆栈信息以及一些服务异常的硬件堆栈信息（如双重故障，NMI，堆栈错误，调试，MCE）。

通过上面这些分析只想说明一点，整个流程是没有问题的。到目前为止只有第一行日志信息还没有找到输出的地址，其实看源码很容易就看出来了，就在WARN_ON宏的上一行代码就是了，代码如下：

Printk函数的作用相当于printf，只是这个是专门用于内核的（有一些特殊实现）。通过一句代码我们也可以发现local_clock_stable是为0，因为没有打印最后那一点信息出来。到这里为止基本把第一阶段出现内核错误和bug的代码全部理解清楚了（日志时间为：Dec 4 14:03:34这个时间输出的），后面附件具体分析导致这个原因代码的原因。

（2）第二阶段（时间在Dec 4 14:03:41，与第一阶段只相差了几秒钟，应该还是存在一定的关联）内核错误日志输出代码分析，这部分日志输出显示了导致了cpu软死锁。

下面首先需要分析一下什么情况下会调用这个函数并且导致cpu软死锁，根据第二部分cpu软死锁产生原因的分析，每一个cpu都会启动一个对应的watchdog线程来监控cpu的执行状态，创建watchdog线程是在使能watchdog功能的时候，在函数watchdog_enable里面实现，代码如下：

从上面这个watchdog使能函数可以看出，每一个cpu的watchdog监控线程的入口函数是watchdog函数，还注册了一个softlockup软死锁响应函数。下面开始从watchdog函数继续开始分析，代码如下：

这个函数首先设置watchdog线程的cpu的调度策略为FIFO（先来先服务），并且优先级最低，然后初始化一个时间戳，设置当前的cpu状态为可中断的状态。然后就进入while循环了，通过while循环上面的注释我们可以清楚的知道每一秒钟都会重新设置softlockup的时间戳，如果超过60秒钟那么就会触发debug信息被打印，打印信息是在函数watchdog_timer_fn里面，这个函数是在watchdog模块初始化的时候注册的，每一个模块加载最先执行的都是模块初始化函数，当然卸载模块的时候也有相应的资源清理函数。

到这里为止我们知道了如果要打印出我们服务器内核的错误信息就必须得满足一个条件，就是已经超过60秒钟没有重新设置softlockup的时间戳了（每一，秒钟重新设置softlockup的时间戳，有一个比较通俗的说法叫做喂狗，因为上面的watchdog程序也俗称看门狗程序，cpu就是通过这种方式来检测cpu是否运行正常的，已经超过60秒钟没有喂狗了，那么狗肯定饿了，也就是cpu处于饥饿状态，浪费了cpu的时间了，最大的可能就是cpu产生了软死锁）。这里就不详细分析cpu调度相关的功能了，还是继续分析产生这种bug的原因。下面最主要的就是分析为什么超过60秒钟没有喂狗（重新设置softlockup时间戳）了。分析这个应该需要结合第一阶段的错误日志分析，第一阶段也是由于计算时间差值大于了一个设定的时间。

         上面我们已经分析到了函数watchdog_timer_fn打印debug信息的地方了，这个函数的在前面已经粘贴出来了，我们结合我们的错误日志分析一下对应的输出内核，通过函数的分析下面这句代码就是打印我们第二阶段错误日志信息的第一条：

而输出这一条的条件就是linux内核检测出了已经存在软死锁（通过前面if条件判断的代码以及前面的代码注释都可以说明这一点），通过这条日志信息我们可以看到cpu的逻辑编号、进程名称和进程id（通过我们的日志信息可以看出分别是11、qmgr进程、进程id是5492）。我们在看看一个更重要的值，这个值就是决定了是否产生了软死锁，这个值就是duration，这里显示是秒。下面详细分析一下这个值是怎么被计算出来的，通过代码发现是通过下面这个函数计算出来的：

30LL;这句代码计算出来的）。接着通过调用time_after函数判断现在的时间戳now与上一次喂狗的时间戳加上softlockup_thresh（60）的先后关系，也就是判断是不是有超过60秒钟没有喂狗了，如果是就会返回一个现在的时间戳减去上一次喂狗的时间戳，如果没有就会返回0。根据我们的日志信息，很明显已经超过了，所以返回值不为0，就导致了软死锁被检测到。

后面接着打印了linux内核加载了的相关模块信息，然后打印中断trace的事件信息，一直跟踪下去，发现和我们打印的内核bug信息完全符合。

下面开始分析一下call trace，不管是第一阶段的日志还是第二阶段的日志堆栈最上层的函数都是tracesys，说明这些信息都是在trace子系统中发生的，至少说明当时都处于trace子系统的运行。其实tracesys是用汇编实现的，主要用于跟踪系统调用的功能。第二阶段的call trace基本是没有什么信息，分析不出什么效果。有一点需要说明一下，第一阶段的日志打印的信息显示是master进程，第二阶段显示是qmgr进程。在centos上master进程是qmgr进程的父进程。下面看第一阶段日志的call trace信息，如下（去掉了公共前缀信息）：

我们首先看一下这个函数的参数：其中有两个比较复杂和重要的结构体ring_buffer_per_cpu和ring_buffer，分析这两个结构体主要是为了后面的函数内部分析做一个准备。我们先看看ring_buffer结构体（简称为RB结构体）的定义，如下：

在RB的操作中,我们可以禁止全局的RB操作，例如，完全禁用掉Trace功能后，整个RB都是不允许再操做的，这时，就可以将原子变量record_disabled 加1。相反的，如果启用的话,将其减1即可。只有当record_disabled的值等于0时，才允许操作RB。

同时，有些时候,要对RB的一些数据进行更新，比如，我要重新设置一下RB的缓存区大小，这都需要串行操作，因此，在ring_buffer结构中有mutex成员，用来避免这些更改RB的操作的竞争。

我们也可以看到，每个cpu都有一系列的页面，这样页面都链入在pages中。

具体的缓存区是由structbuffer_data_page指向的,实际上,它是具体页面的管理头部,结构如下:

把所有基本的结构体解析清楚以后我们就可以正在分析这个函数了，代码已经在前面写出来了。函数里面首先定义了一个ring_buffer_event结构体的变量，先看一下这个结构体的定义如下：

这个结构体注释提醒不要直接使用，只能在函数体里面使用，这里是在函数体里面定义和使用的。里面加入了动态内存检测的字段kmemcheck，这个特性类似用户态动态内存检测工具valgrind，只是实现上有很大的区别，而且这个主要是用于内核动态内存检测技术。继续上面函数的分析，然后定义了一些需要用到的变量。继续就开始调用函数rb_start_commit，函数代码如下：

其实最终就是使用汇编实现一个长整型变量的原子加（addl）1操作。接下来是一段需要使能了RB交换swap功能（和虚拟内存交换，linux系统称为交换区，有硬盘充当）。接下来调用函数rb_calculate_event_length计算事件长度。继续我们就会看到一大段英文注释，大体上是说，在调用这个函数之前禁止了抢占，中断和NMI在这里存在着竞争，因此在下面的运行中,随时都会被中断/NMI所抢占。由于在从struct ring_buffer_per_cpu中取页面的时候，会有当前页面空间不足，需要前进一个页面的情况.每次前进一个页面都会跳转到again，此时nr_loops都会增加1，如果在一次请求中,这样的情况出现了1000次，说明中断抢占的次数太多了，很可能是由于中断风暴(interrupte trace信息，根据我们的服务器日志这里没有打印。继续就是调用函数ring_buffer_time_stamp取当前的时间戳并赋值给ts临时变量。下面又是一大段英文注释，意思是只有第一次处于提交状态的请求才能够更新cpu_buffer->write_stamp（cpu的写时间戳），这里存在着竞争。下面详细分析这里代码执行的情况，因为涉及到delta计算的问题，这也是导致我们服务器bug的最基本和开始的原因。

从这里的if判断可以看到，只有在fistcommit的时候才会计算delta，其它的情况下，会获取下一个event。我们来思考一下，为什么在确认了是fist commit，进入到了if，还需要进行:

的判断呢？ 这个delta到底是用来做什么的呢?它为什么要用这样的判断方式呢？我们在之前说过，在ring_buffer_per_cpu中的每一块数据都带有一个event的头部，即:

它里面有一个time_delta的成员占27位。在每一个页面的头部，即Structbuffer_data_page里面也有一个时间戳，即：

那这几个时间戳有什么样的关联呢？在ring_buffer_per_cpu中有一个timestamp，它表示最近commit时的时间戳。每次切换进一个新页面时，该页面对应的：

综上所述,存在以下关系：

页面中的第一个event，event1在进行写操作时的时间戳为：

第二个event,event2在进行写操作时的时间戳为：

分析到这里我们发现计算出来的delta值超过了设定的阀值，所以打印处理debug信息，我们分析一下打印出来的几个时间值（应该是系统节拍值），日志如下：

cpu_buffer->write_stamp;通过计算器计算确实满足。那下面在看看ts是怎么计算出来的，他是计算linux服务器冲启动到现在的节拍数，和设置的HZ有关系，最终还是调用sched_clock函数计算所得，这个函数代码实现如下：

以上函数是cpu调度的节拍数计算方式，全局变量jiffies用来记录从系统启动以来产生的节拍的总数，启动时，内核将该变量初始化为INITIAL_JIFFIES，网上有的说法又是初始化为0，为了验证到底初始化为多少我们使用一个内核模块在启动的时候就把这个值打印出来看一看就清楚，通过测试初始化值确实是INITIAL_JIFFIES。此后，每次时钟中断处理程序都会增加该变量的值。一秒内时钟中断的次数等于HZ，所以jiffies一秒内增加的值也就是HZ。系统运行时间以秒为单位，等于jiffies/HZ。注意，jiffies类型为无符号长整型(unsigned long)，其他任何类型存放它都不正确。将以秒为单位的时间转化为jiffies：seconds * Hz。将jiffies转化为以秒为单位的时间：jiffies / HZ。HZ的值在param.h中设置为100，那么通过日志中打印出来的ts值（单位是纳秒）计算服务器已经启动了多少天：/60/60=213504（天），这个值明显不对，那我们在计算一下上一次cpu记录的写入值（write stamp = 46377）是否正确？同样的计算方式如下：/60=208（天）这个值还算比较正确，就是上一次写入对应的值已经是208天以前的时候。

SEC_PER_SEC是每一秒钟的纳秒数（）。

于是整个表达式计算为：系统当前运行的节拍值（INITIAL_JIFFIES计算所得），然后再除以/100=。从我们的日志中可以看出当前计算出来的值是ts：。根据这个值我们可以反推出jiffies-INITIAL_JIFFIES=2。这个值明显不对，在看cpu软死锁产生的一条日志信息如下：

通过这条日子好也可以看出这个时间s完全不正常。造成这种不正常的原因可能是内存破坏造成的。

新发现：在使用内核模块修改jiffies值的时候，直接导致了centos产生了cpu softlockup错误，而且从内核打印出的错误信息可以看出最后加载的模块就是我写的那个测试模块，对比线上服务器崩溃的内核日志查看最后加载的内核模块是scsi_scan_wait。由此可以推断可能是由于scsi_scan_wait这个内核模块导致了qmgr进程产生了cpu软死锁，也就是导致了qmgr已经超过了60秒没有得到中断响应了。

         由于一直不能重现这个错误，所以一直没有排查出问题的正在原因，目前还是继续排查，想办法还原错误。如果有哪位以前遇到过同样的问题并且得到了解决麻烦告知一声，非常感谢！

上投摩根安泽回报混合型证券投资基金招募说明书