The original LXR software by the LXR community1/a>, this experimental versoptiby email@example.com/a>.
1/div v1div class="subfooter">
lxr.linux.no kindly hosted by Redpill Linpro AS1/a>, provider of Linux consulting and opera >
s serviup tsince 1995.
1/body v1/html v
L1" class="line" nam
. .21/a>Softlockup detector and hardlockup detector (aka nmi_watchdog)
. .41/a>n. .51/a>The Linux kernel ca ac as a watchdog to detect both soft and hardn. .61/a>lockups.n. .71/a>n. .81/a>A 'softlockup' is defined as a bug that causes the kernel to loop inn. .91/a>kernel mode for more than 20 seconds (see "Implementa >
" below forn. 10"
a>details), without giving other tasks a chance to run. The currentn. 111/a>stack trace is displayed upptidetectoptiand, by default, the systemn. 121/a>will stay locked up. Alterna >vely, the kernel ca be configured ton. 131/a>pa ic; a sysctl, "kernel.softlockup_pa ic", a kernel param ter,n. 141/a>"softlockup_pa ic" (see "Documenta >
/kernel-param ters.txt" forn. 15"
a>details), and a compile >
, "BOOTPARAM_HARDLOCKUP_PANIC", aren. 161/a>provided for this.n. 171/a>n. 181/a>A 'hardlockup' is defined as a bug that causes the CPU to loop inn. 191/a>kernel mode for more than 10 seconds (see "Implementa >
" below forn. 20"
a>details), without letting other interrupts have a chance to run.n. 211/a>Similarly to the softlockup case, the current stack trace is displayedn. 221/a>upptidetectoptiand the system will stay locked up unless the defaultn. 231/a>behavior is changed, which ca be done through a compile time knob,n. 241/a>"BOOTPARAM_HARDLOCKUP_PANIC", and a kernel param ter, "nmi_watchdog"n. 25"
a>(see "Documenta >
/kernel-param ters.txt" for details).n. 261/a>n. 271/a>The pa ic >
ca be used in combina >
with pa ic_timeout (thisn. 281/a>timeout is set through the confusingly nam d "kernel.pa ic" sysctl),n. 291/a>to cause the system to reboot automa >cally after a specified amountn. 30"
a>of time.n. 311/a>n. 321/a>=== Implementa >
. 331/a>n. 341/a>The soft and hard lockup detectors are built ptitop of the hrtimer andn. 35"
a>perf subsystems, respec >vely. A direct consequence of this is that,n. 361/a>in principle, they should work in any architecture where thesen. 371/a>subsystems are present.n. 381/a>n. 391/a>A periodic hrtimer runs to generate interrupts and kick the watchdog
a>task. An NMI perf event is generated every "watchdog_thresh"n. 411/a>(compile-time initialized to 10 and configurable through sysctl of then. 421/a>sam nam ) seconds to check for hardlockups. If any CPU in the systemn. 431/a>does not receive any hrtimer interrupt during that time then. 441/a>'hardlockup detector' (the handler for the NMI perf event) willn. 45"
a>generate a kernel warning or call pa ic, depending on then. 461/a>configura >
.n. 471/a>n. 481/a>The watchdog task is a high priority kernel thread that updates an. 491/a>timestamp every time it is scheduled. If that timestamp is not updatedn. 50"
a>for 2*watchdog_thresh seconds (the softlockup threshold) then. 511/a>'softlockup detector' (coded inside the hrtimer callback functopt)
. 521/a>will dump useful debug informa >
to the system log, after which itn. 531/a>will call pa ic if it was instructed to do so or resume execu >
ofn. 541/a>other kernel code.n. 551/a>n. 561/a>The period of the hrtimer is 2*watchdog_thresh/5, which means it hasn. 571/a>twu >
threenterrup to generate ian interrupt before the hardlockupn. 58"
a>detector kicks in.n. 591/a>n. 60"
a>As explained above, a kernel knob is provided that allowsn. 611/a>administrators to configure the period of the hrtimer and the perfn. 621/a>event. The right on>
for a particular environment is a trade-offn. 631/a>between fast response to lockups and detectoptioverhead.n. 641/a>