CN103530197B - 一种检测及解决Linux系统死锁的方法 - Google Patents
一种检测及解决Linux系统死锁的方法 Download PDFInfo
- Publication number
- CN103530197B CN103530197B CN201310522839.7A CN201310522839A CN103530197B CN 103530197 B CN103530197 B CN 103530197B CN 201310522839 A CN201310522839 A CN 201310522839A CN 103530197 B CN103530197 B CN 103530197B
- Authority
- CN
- China
- Prior art keywords
- cpu
- software
- thread
- variable
- deadlock
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明提供一种检测及解决Linux系统死锁的方法。该方法包括:处理器的至少两个CPU具有各自的定时器,并且分别绑定自身的软件看门狗线程;a)每个CPU空闲时,执行对自身绑定的软件看门狗线程的调度,该软件看门狗线程被调度后其对应的调度计数变量值进行累加;b)每个CPU对应的定时器到达预设的定时时间,该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;c)如果所述调度计数变量连续在预设次数未发生变化,则判断其对应的CPU发生死锁。相较于现有技术,本发明通过CPU之间的相互检测,改善了现有技术中各CPU只能对自身进行死锁检测的局限问题,并缩短了检测出系统发生死锁的时长。
Description
技术领域
本发明涉及计算机及信息技术领域,尤其涉及一种检测及解决Linux系统死锁的方法。
背景技术
Linux操作系统被广泛运用在各种服务器上,但是不管是系统软件还是应用软件总会存在bug,从而导致系统出现死锁(lockup)。现有技术的Linux操作系统中的死锁包括软死锁和硬死锁(soft/hard lockup),如果检测到系统发生死锁,则切换到另一系统,用户还可以收集发生死锁的系统的环境信息,并且如果存在紧急业务,则处理所述紧急业务,之后重启发生死锁的系统。
但现有技术方案存在如下缺陷:
1)只检测本CPU是否发生死锁,未检测其它CPU是否发生死锁。
2)硬死锁发生后,检测到发生硬死锁的时间过长,从1分钟到5分钟不等,甚至更长。并且由于检测到发生硬死锁的时间过长,导致无法收集发生死锁的系统的环境信息,以及无法进行紧急业务的处理。
发明内容
有鉴于此,本发明提供一种检测及解决Linux系统死锁的方法,本发明可以通过处理器的至少两个CPU之间的相互检测,确定所述至少两个CPU是否发生死锁。
具体来说,本发明一种检测及解决Linux系统死锁的方法,该方法应用于包含至少两个CPU的处理器上;
所述至少两个CPU具有各自的定时器,并且分别绑定自身的软件看门狗线程,每个软件看门狗线程对应自身的调度计数变量;
该方法包括如下步骤:
a)每个CPU空闲时,执行对自身绑定的软件看门狗线程的调度,该软件看门狗线程被调度后其对应的调度计数变量值进行累加;
b)每个CPU对应的定时器到达预设的定时时间,该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;
c)如果所述调度计数变量连续在预设次数未发生变化,则判断其对应的CPU发生死锁。
进一步地,所述步骤b)每个CPU对应的定时器到达预设的定时时间后该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测前进一步包括:
该CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;如果是,则返回步骤a);否则,执行对各CPU软件看门狗线程对应的调度计数变量的检测。
进一步地,各CPU对应一个已检测标志变量,该已检测标志变量包括若干比特位,每一个CPU的检测状态用一个比特位对应表示,该已检测标志变量值初始值为零;
所述该CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测包括:已检测标志变量是否已赋值,且其对应的比特位是否未置位,如果是,则确认本轮已有CPU执行检测,否则确认本轮没有CPU执行检测;
当确认本轮已有CPU执行检测时,该CPU将已检测标志变量中对应自身的比特位置位,返回步骤a);当确认本轮没有CPU执行检测时,该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测,同时先将已检测标志变量赋零值,再将该CPU已检测标志变量中对应自身的比特位置位。
进一步地,所述软件看门狗线程还进一步包括在软件看门狗线程中设置可中断标志,保证软件看门狗线程睡眠后能被其他信号唤醒。
进一步地,该方法还包括通过硬件看门狗及NMI中断在预设的时间内检测系统是否发生死锁。
进一步地,设定NMI的中断触发时间,当NMI中断来临,从NMI中断处理函数中读取时间差值,如果时间差值大于预设的时间值,则判定发生死锁。
进一步地,所述的时间差值为硬件看门狗最后一次清零到NMI中断发生时的时长。
由此可见,本发明通过CPU之间的相互检测,改善了现有技术中各CPU只能对自身进行死锁检测的局限问题,并且通过合理设置软件看门狗定时器计数时间及NMI中断与硬件看门狗定时器配合中断检测时间,缩短了检测出系统发生死锁的时长,使得用户能够及时的收集环境信息及紧急业务的处理,让系统及时回到可用状态。
附图说明
图1是本发明软件看门狗定时器中断处理函数CPU相互检测流程图;
图2是本发明NMI中断处理函数流程图。
具体实施方式
下面结合附图及以计算机程序实现为例对本发明再作进一步详细的说明。
本发明一种的实施方式中(以计算机程序实现为例)的本发明一种检测及解决Linux系统死锁的方法,该方法应用于包含至少两个CPU的处理器上;
在优选的实施方式中,本发明方法具体如下:
至少两个CPU具有各自的定时器,并且分别绑定自身的软件看门狗线程,每个软件看门狗线程对应自身的调度计数变量;
软件看门狗定时器为循环定时器,优选地本实施例设定各CPU软件看门狗定时器中断时间为6秒产生一次中断。
请参考图1,是本发明软件看门狗定时器中断处理函数CPU相互检测流程图。其运行过程涉及以下处理流程:
a)每个CPU空闲时,执行对自身绑定的软件看门狗线程的调度,该软件看门狗线程被调度后其对应的调度计数变量进行累加;
系统第一次启动时初始化CPU的软件看门狗线程,设置软件看门狗线程的可中断状态标志位为可中断状态,本CPU软件看门狗线程调度计数变量值由零自动累加为1,进入睡眠状态等待被唤醒。
CPU执行完所有任务后在空闲状态下会去执行本软件看门狗线程,软件看门狗线程中的调度计数变量值会自动进行累加。
对软件看门狗线程初始化目的是使各CPU的软件看门狗线程启动,设置软件看门狗线程状态为可中断状态是为了软件看门狗线程睡眠后,可以被其它的信号唤醒。
b)每个CPU对应的定时器到达预设的定时时间,该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;
在各CPU软件看门狗定时器中断处理函数中,对软件看门狗定时器赋初值,使CPU软件看门狗定时器定时6秒计数溢出,定时器中断发生,软件看门狗定时器发生中断的CPU会执行唤醒本CPU软件看门狗线程的动作,并监测本CPU及其他CPU软件看门狗线程的调度计数变量值是否变化。
c)如果所述调度计数变量值连续在预设次数未发生变化,则判断其对应的CPU发生死锁。
对于上述CPU相互检测还包括已检测标志变量的检测;
因为每个CPU都配有一个软件看门狗定时器,因而要避免每轮的重复检测,因此定义一个已检测标志变量,该已检测标志变量是一个全局的变量,包括若干比特位,每一个CPU的检测状态用一个比特位对应表示,该已检测标志变量值初始值为零。每个CPU在自身的定时器到达预设的定时时间时,查看该已检测标志变量。
当有CPU软件看门狗定时器发生中断时,该CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;如果是,则返回步骤a);否则,执行对各CPU软件看门狗线程对应的调度计数变量的检测。
该CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测包括:已检测标志变量是否已赋值,且其对应的比特位是否未置位,如果是,则确认本轮已有CPU执行检测,否则确认本轮没有CPU执行检测;当确认本轮已有CPU执行检测时,该CPU将已检测标志变量中对应自身的比特位置位,返回步骤a);当确认本轮没有CPU执行检测时,该CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测,同时先将已检测标志变量清零,再将该CPU已检测标志变量中对应自身的比特位置位。
已检测标志变量包括若干个比特位,通常多核处理器包含几个CPU该已检测标志变量具有几个比特位,每个比特位对应一个CPU。当然已检测标志变量的比特位数大于CPU的数量也是可以的。该已检测标志变量已赋值是指对应任一CPU的比特位被置1;已检测标志变量的比特位未被置位是指比特位为零,被置位是指该比特位为1。
以下举个例子来说明如何判断本轮是否有CPU检测的流程,假设处理器有4个CPU,那么就有4个6秒软件看门狗定时器中断,已检测标志变量初始值为0。
系统启动后,第一次假定是CPU0的软件看门狗定时器中断先触发,发现已检测标志变量的值为0,那么就认为本轮没有CPU检查,然后将0赋给已检测标志变量,并把已检测标志变量中表示CPU0的第0个比特位置1,此时已检测标志变量的值就是1;
此时CPU1的软件看门狗定时器中断也触发了,检测到已检测标志变量的值是1,且已检测标志变量中表示CPU1的第1位比特位为0,就把已检测标志变量中表示CPU1的第1位比特位为置1,此轮不用启动对各CPU的检测,直接返回;
因为检测标志变量中第0位和第1位都已经被置1了,此时已检测标志变量的值就是3。其它的CPU依此类推,当有4个CPU的时候,我们可以发现一轮全部检查完后已检测标志变量的值为15,也就是1111(二进制)。
此时,假设CPU1的软件看门狗定时器定时6秒计数溢出,中断触发了,CPU1检测发现此时已检测标志变量的值不为0(此时已检测标志变量值为15),已检测标志变量中表示CPU1的第1位比特位为是1(因为上轮检测时已将该比特为置1),不满足本轮已有CPU检测的条件,那么就认为,这轮没有CPU进行检测。于是就把已检测标志变量清零,已检测标志变量中表示CPU1的第1位比特位为置1,此时已检测标志变量的值就变为2。而当其它CPU的软件看门狗定时器定时6秒计数溢出中断触发后,发现已检测标志变量不为0,自己的比特位是0,标明本轮已有CPU在检测,于是只需置上本CPU的标志位为1就可以了,不用再作检测了。后续的循环检测过程不再赘述。
当判断本轮已有CPU检测时,将本CPU比特位置1的目的是为了防止执行死锁检测的CPU在检测过程中自身发生了死锁,而导致检测不能正常进行的问题。具体地,当前有CPU在执行死锁检测,其他CPU如不做置本CPU标志位的动作,则已检测标志变量的值就没有办法改变,当执行死锁检测的CPU在检测过程中自身发生了死锁,其他CPU就会认为有CPU在正常的执行死锁检测。但是如果其他CPU判断本轮已有CPU执行检测后,将已检测标志变量中对应自身的比特位置1,那么即使当前在执行死锁检测的CPU在检测过程中自身发生死锁,最终已检测标志变量各CPU对应的比特位也会全部被置位。当某个到达定时时间的CPU发现已检测标志变量各CPU对应的比特位全部被置位时,就可以确定当前没有CPU在执行对各CPU的死锁检测,从而自己作为检测者执行对各CPU的死锁检测,从而避免执行检测的CPU发生死锁而导致检测不能正常进行的问题。
对各CPU执行死锁检测的CPU具体按照如下流程执行死锁检测:首先检测CPU软件看门狗线程是否已启动,如果所检测的CPU软件看门狗线程未启动,则不继续对该CPU检测,返回循环检测下一个CPU软件看门狗线程是否启动,如所检测的CPU软件看门狗线程已启动,则继续查看所检测的CPU软件看门狗线程中调度计数变量值是否变化;如所检测的CPU软件看门狗线程中调度计数变量值已变化,表明该CPU运行正常,将未被调度计数变量清零;如所检测的CPU软件看门狗线程中调度计数变量值未变化,则未被调度计数变量自动累加,返回进行其他CPU检测。当所有CPU都检测完成等待定时中断来临进行又一轮检测。如果未调度计数变量值累加到15(约90秒,因为设定的软件看门狗定时器中断计数时间为6秒中断1次),即软件看门狗线程对应的调度计数变量连续15次没有发生变化,则判定该CPU发生死锁。这里的15次仅是举例,本发明对此并不作限定。
如果检测到有CPU发生死锁,则检测到死锁的CPU被触发切换到另一系统,同时收集发生死锁系统的环境运行信息并自动重启所述发生死锁的系统。让系统回到可用状态。
现有技术中各CPU只对自身做检测,所以如果该CPU发生hard lockup(硬死锁)的话,此种检测的方法就无法检测出硬死锁。而本发明的方案采用了CPU相互检测的方法,当多个CPU中有某一CPU发生硬死锁时,其他CPU能将其检测出来。
本发明还包括通过硬件看门狗及NMI中断在预设的时间内检测系统是否发生死锁,请参考图2。
由所在技术领域人员根据实际情况进行设定,设置计时周期硬件计数器计数,定时产生中断,软件定时要在硬件看门狗定时器置零前给它一个信号,让它重新计时,俗称“喂狗”,使狗复位,这样起到一个监视系统运行的作用。当系统出现故障时,如长时间没有“喂狗”,则硬件看门狗将以复位信号作出响应,复位中断产生,复位系统。
为使硬件看门狗不进行复位系统,则需保证软件能定时喂狗,使硬件看门狗重新计数,所以需设定一个监测阈值,通过读取硬件看门狗寄存器的值与监测阈值的比较来判断系统是否运行正常,在系统复位前能及时的发现系统故障,进行处理。
本发明通过设置NMI的中断触发时间,优选地本实施例设定NMI中断触发时间为1分钟内至少要触发2次NMI中断,则约30秒发生一次中断,当NMI中断发生时去读取硬件看门狗寄存器的值;并且根据NMI中断触发时间预设一个用来监测硬件看门狗发生复位中断的比对阈值,本实施例预设的比对阈值为55秒。
当NMI中断来临,在NMI中断时读取硬件看门狗寄存的值,获取软件最后一次喂狗到当前的时间差值,如果时间差值大于预设的阈值,表明软件没有去喂狗,则判定发生死锁。时间差值为硬件看门狗最后一次清零到NMI中断发生时的时长。
本实施例中预设在每计数30秒NMI发生一次中断,则判断此时读取的时间差值是否大于设定的阈值55秒,如时间差值大于设定的阈值55秒,则判定为系统发生了死锁。
如果检测系统发生死锁,则切换到另一系统,同时收集发生死锁系统的环境运行信息并自动重启所述发生死锁的系统。让系统回到可用状态。
为保证系统发生死锁时,能继续读到时间差值,则读取时间差值的判定放在NMI中断处理函数中执行。
假如硬件看门狗定时器刚清零后死锁就发生,此时等待下次NMI中断来临时的最长时间不超过1分钟。通过NMI中断触发时间的设定,及对时间差值的判断使得在不超过2分钟就能检测出系统发生死锁。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (6)
1.一种检测及解决Linux系统死锁的方法,该方法应用于包含至少两个CPU的处理器上,其特征在于,
所述至少两个CPU具有各自的定时器,并且分别绑定自身的软件看门狗线程,每个软件看门狗线程对应自身的调度计数变量;
该方法包括如下步骤:
a)每个CPU空闲时,执行对自身绑定的软件看门狗线程的调度,该软件看门狗线程被调度后其对应的调度计数变量值进行累加;
b)每个CPU对应的定时器到达预设的定时时间,定时器到达预设的定时时间的CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;
c)如果所述调度计数变量连续在预设次数未发生变化,则判断其对应的CPU发生死锁;
所述步骤b)每个CPU对应的定时器到达预设的定时时间后,定时器到达预设的定时时间的CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测前进一步包括:
定时器到达预设的定时时间的CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测;如果是,则返回步骤a);否则,执行对各CPU软件看门狗线程对应的调度计数变量的检测。
2.如权利要求1所述的方法,其特征在于,各CPU对应一个已检测标志变量,该已检测标志变量包括若干比特位,每一个CPU的检测状态用一个比特位对应表示,该已检测标志变量值初始值为零;
所述定时器到达预设的定时时间的CPU判断本轮是否已有CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测包括:已检测标志变量是否已赋值,且CPU对应的比特位是否未置位,如果是,则确认本轮已有CPU执行检测,否则确认本轮没有CPU执行检测;
当确认本轮已有CPU执行检测时,定时器到达预设的定时时间的CPU将已检测标志变量中对应自身的比特位置位,返回步骤a);当确认本轮没有CPU执行检测时,定时器到达预设的定时时间的CPU执行对各CPU软件看门狗线程对应的调度计数变量的检测,同时先将已检测标志变量赋零值,再将该CPU已检测标志变量中对应自身的比特位置位。
3.如权利要求1所述的方法,其特征在于,所述软件看门狗线程还进一步包括在软件看门狗线程中设置可中断标志,保证软件看门狗线程睡眠后能被其他信号唤醒。
4.如权利要求1所述的方法,其特征在于,该方法还包括通过硬件看门狗及NMI中断在预设的时间内检测系统是否发生死锁。
5.如权利要求4所述的方法,其特征在于,设定NMI的中断触发时间,当NMI中断来临,从NMI中断处理函数中读取时间差值,如果时间差值大于预设的时间值,则判定发生死锁。
6.如权利要求5所述的方法,其特征在于,所述的时间差值为硬件看门狗最后一次清零到NMI中断发生时的时长。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310522839.7A CN103530197B (zh) | 2013-10-29 | 2013-10-29 | 一种检测及解决Linux系统死锁的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310522839.7A CN103530197B (zh) | 2013-10-29 | 2013-10-29 | 一种检测及解决Linux系统死锁的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103530197A CN103530197A (zh) | 2014-01-22 |
CN103530197B true CN103530197B (zh) | 2017-06-13 |
Family
ID=49932232
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310522839.7A Active CN103530197B (zh) | 2013-10-29 | 2013-10-29 | 一种检测及解决Linux系统死锁的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103530197B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10185564B2 (en) * | 2016-04-28 | 2019-01-22 | Oracle International Corporation | Method for managing software threads dependent on condition variables |
CN108459984A (zh) * | 2018-02-02 | 2018-08-28 | 郑州云海信息技术有限公司 | 一种机柜i2c总线死锁处理方法、系统、介质及设备 |
CN110413260A (zh) * | 2019-06-19 | 2019-11-05 | 四川长虹电器股份有限公司 | 高争用环境下的细粒度锁设计方法 |
CN114640635B (zh) * | 2022-03-17 | 2024-02-09 | 新华三技术有限公司合肥分公司 | Pfc死锁的处理方法及装置 |
CN116156860B (zh) * | 2023-02-22 | 2024-03-08 | 北京航天发射技术研究所 | 一种电驱特种车辆同步伺服控制器的电磁兼容优化方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1815449A (zh) * | 2005-02-01 | 2006-08-09 | 艾默生网络能源有限公司 | 看门狗控制方法 |
CN101188828A (zh) * | 2006-11-16 | 2008-05-28 | 中兴通讯股份有限公司 | 双处理器移动终端监控处理从处理器工作状态的方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002189614A (ja) * | 2000-12-22 | 2002-07-05 | Nec Microsystems Ltd | ウォッチドッグタイマとそれを内蔵したマイクロコンピュータ及びマイクロコンピュータの暴走防止制御方法 |
JP4393954B2 (ja) * | 2004-09-09 | 2010-01-06 | Okiセミコンダクタ株式会社 | マイクロコンピュータ |
JP5063212B2 (ja) * | 2007-06-25 | 2012-10-31 | 株式会社日立産機システム | 複数コンポーネントシステム |
CN101957790B (zh) * | 2009-11-26 | 2012-11-07 | 上海大学 | 微控制器多源看门狗的实现方法 |
-
2013
- 2013-10-29 CN CN201310522839.7A patent/CN103530197B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1815449A (zh) * | 2005-02-01 | 2006-08-09 | 艾默生网络能源有限公司 | 看门狗控制方法 |
CN101188828A (zh) * | 2006-11-16 | 2008-05-28 | 中兴通讯股份有限公司 | 双处理器移动终端监控处理从处理器工作状态的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103530197A (zh) | 2014-01-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103530197B (zh) | 一种检测及解决Linux系统死锁的方法 | |
CN101452420B (zh) | 一种嵌入式软件异常监控和处理装置及其方法 | |
CN100359481C (zh) | 多任务系统的异常监控装置及其方法 | |
CN102761439B (zh) | Pon接入系统中基于看门狗的异常检测记录装置及方法 | |
US20170147422A1 (en) | External software fault detection system for distributed multi-cpu architecture | |
US9459949B2 (en) | Methods and apparatus to provide failure detection | |
CN100361081C (zh) | 处理多线程/多任务/多处理器的方法 | |
CN105550057B (zh) | 嵌入式软件系统故障检测恢复方法和系统 | |
CN106959895B (zh) | 快速释放线程的资源调度方法和系统 | |
US20150006978A1 (en) | Processor system | |
EP2021925B1 (en) | Arbiter diagnostic apparatus and method | |
CN111796954A (zh) | 基于jvm的看门狗的控制方法、装置、设备及存储介质 | |
CN106844082A (zh) | 处理器预测故障分析方法及装置 | |
CN105824709B (zh) | 一种临界区访问方法及装置 | |
US9009537B2 (en) | Diagnostic data capture in a computing environment | |
CN106874126A (zh) | 一种软件开发中主进程异常检测方法 | |
JP2001318807A (ja) | タスク切り替え制御方法及び装置 | |
JP2965075B2 (ja) | プログラム実行状態監視方法 | |
CN109376027A (zh) | 一种异常销毁进程的处理方法及终端 | |
CN102053902A (zh) | 操作系统的监控方法 | |
JP2006227962A (ja) | アプリケーションタスク監視システムおよび方法 | |
CN115576734A (zh) | 一种多核异构日志存储方法和系统 | |
CN104050051A (zh) | 一种星载计算机的故障诊断方法 | |
US20180341519A1 (en) | Node-local-unscheduler for scheduling remediation | |
JP6765874B2 (ja) | 電子制御装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |