[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectNMI watchdog setup_lapic_nmi_watchdog() problem

I was doing some more testing with perfmon when I ran into
a problem with the NMI watchdog code in 2.6.27-rc8.

Since 2.6.20, it is possible to enable/disable the NMI watchdog
on-the-fly via /proc/sys/kernel/nmi_watchdog. This is a nice option
which avoids having to reboot the kernel.

Enabling/disabling the NMI watchdog uses two internal functions
enable_lapic_nmi_watchdog() and disable_lapic_nmi_watchdog().

Enable_lapic_nmi_watchdog() uses a IPI handler to setup the
APIC on each CPU. However, it turns out that this handler, namely,
setup_apic_nmi_watchdog() relies on some explicit ordering constraint
due to suspend/resume constraints as explained in the comment

void setup_apic_nmi_watchdog(void *unused)
if (__get_cpu_var(wd_enabled))

/* cheap hack to support suspend/resume */
/* if cpu0 is not active neither should the other cpus */
if (smp_processor_id() != 0 && atomic_read(&nmi_active) <= 0)

switch (nmi_watchdog) {

Supposing watchdog was disabled via /proc, nmi_active = 0. Then if you
re-enable, and if CPU0 is not the first to execute the IPI handler, then none
of the other CPUS will re-enable their NMI watchdog timer. On a quad-core
system, I have seen, for instance, 2 out of 4 with NMI watchdogs re-enabled.

I am not an expert at suspend/resume. I am assuming there was a race condition
there and that's why this code was added early on. The problem is that it now
conflicts with the /proc option.

It is not clear to me how this works during boot. Obviously the order
is respected
and all CPUs have their NMI watchdog enabled.

Until I understand the suspend/resume issue, it is hard to provide a
fix for this.

Any comments?

 \ /
  Last update: 2008-10-07 17:47    [W:0.106 / U:2.424 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site