summaryrefslogtreecommitdiff
path: root/arch/x86/kernel/vmi_32.c
diff options
context:
space:
mode:
authorAristeu Rozanski <aris@redhat.com>2008-09-22 17:14:13 (GMT)
committerIngo Molnar <mingo@elte.hu>2008-09-22 17:48:18 (GMT)
commit28b166a700899a0f88b1cc283c449fb5bf72a635 (patch)
treeaebb983bd9f2aa6174f9ec8d3e658496c3231354 /arch/x86/kernel/vmi_32.c
parent72d31053f62c4bc464c2783974926969614a8649 (diff)
downloadlinux-28b166a700899a0f88b1cc283c449fb5bf72a635.tar.xz
x86, NMI watchdog: when booting with reset_devices, clear the performance counters
P4s have a quirk that makes necessary to clear P4_CCCR_OVF bit on the CCCR everytime the PMI is triggered. When booting the kernel with reset_devices (more specific kdump case), the counters reach zero and the PMI will be generated. This is not a problem on other processors but on P4s, it'll continue to generate NMIs until that bit is cleared. Since there may be other users of the performance counters, clear and disable all of them when booting with reset_devices option. We have a P4 box here that crashes because of this problem. Since the kdump kernel usually boots with only one processor active, the second logical unit won't be set up, therefore, MSR_P4_IQ_CCCR1 (and other performance counter registers) won't be cleared and P4_CCCR_OVF may be still set because the previous kernel was using this register. An NMI is triggered because of the MSR_P4_IQ_CCCR1 right after the NMI delivery is enabled, triggering the race fixed on my previous email. Signed-off-by: Aristeu Rozanski <aris@redhat.com> Acked-by: Don Zickus <dzickus@redhat.com> Acked-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch/x86/kernel/vmi_32.c')
0 files changed, 0 insertions, 0 deletions