On Sun, May 01, 2005 at 10:04:28AM -0700, Linux Kernel wrote:
> tree 6adb8d33585f8eee20794827c79e40991aeeaee5
> parent fd51f666fa591294bd7462447512666e61c56ea0
> author Jack F Vogel <[email protected]> Sun, 01 May 2005 22:58:48 -0700
> committer Linus Torvalds <[email protected]> Sun, 01 May 2005 22:58:48 -0700
>
> [PATCH] check nmi watchdog is broken
>
> A bug against an xSeries system showed up recently noting that the
> check_nmi_watchdog() test was failing.
>
> I have been investigating it and discovered in both i386 and x86_64 the
> recent change to the routine to use the cpu_callin_map has uncovered a
> problem. Prior to that change, on an SMP box, the test was trivally
> passing because all cpu's were found to not yet be online, but now with the
> callin_map they are discovered, it goes on to test the counter and they
> have not yet begun to increment, so it announces a CPU is stuck and bails
> out.
>
> On all the systems I have access to test, the announcement of failure is
> also bougs... by the time you can login and check /proc/interrupts, the
> NMI count is happily incrementing on all CPUs. Its just that the test is
> being done too early.
>
> I have tried moving the call to the test around a bit, and it was always
> too early. I finally hit on this proposed solution, it delays the routine
> via a late_initcall(), seems like the right solution to me.
My EM64T Dell Precision 470 seems to have problems both before
and after this change, though the behaviour changes.
With -rc3..
testing NMI watchdog ... CPU#1: NMI appears to be stuck (0)!
With -rc4...
Testing NMI watchdog ... CPU#4: NMI appears to be stuck (0)!
The CPU #'s are consistent across reboots (Ie, they're always the same).
Though the rc4 behaviour seems odd, as my CPUs are numbered 0-3.
Bill (Cc'd) also reports that with -rc4, he sees around
a 10 second delay when it does that 'Testing NMI watchdog'
message.
Dave
Dave Jones writes:
> My EM64T Dell Precision 470 seems to have problems both before
> and after this change, though the behaviour changes.
>
> With -rc3..
> testing NMI watchdog ... CPU#1: NMI appears to be stuck (0)!
>
> With -rc4...
> Testing NMI watchdog ... CPU#4: NMI appears to be stuck (0)!
>
> The CPU #'s are consistent across reboots (Ie, they're always the same).
> Though the rc4 behaviour seems odd, as my CPUs are numbered 0-3.
There is known breakage in x86-64's nmi watchdog recently.
One of the problems is that the checking code inspects
all possible CPU numbers [0..NR_CPUS[ and not just the
ones actually present, which leads to false failure reports.
> Bill (Cc'd) also reports that with -rc4, he sees around
> a 10 second delay when it does that 'Testing NMI watchdog'
> message.
And that's another of the known x86-64 breakages.
/Mikael