summaryrefslogtreecommitdiff
path: root/drivers/acpi/resource.c
diff options
context:
space:
mode:
authorBorislav Petkov <bp@suse.de>2013-12-23 21:05:02 +0400
committerBorislav Petkov <bp@suse.de>2014-01-12 18:22:25 +0400
commit4f75d8412792777a314ac5c1393a9ed43d695fd1 (patch)
treef8aa91042ae91baa8abb9f4f127c701cbf84de54 /drivers/acpi/resource.c
parentca104edc17841da87850b20ab77e57fe0a99ead6 (diff)
downloadlinux-4f75d8412792777a314ac5c1393a9ed43d695fd1.tar.xz
x86, mce: Fix mce_start_timer semantics
So mce_start_timer() has a 'cpu' argument which is supposed to mean to start a timer on that cpu. However, the code currently starts a timer on the *current* cpu the function runs on and causes the sanity-check in mce_timer_fn to fire: WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/mcheck/mce.c:1286 mce_timer_fn because it is running on the wrong cpu. This was triggered by Prarit Bhargava <prarit@redhat.com> by offlining all the cpus in succession. Then, we were fiddling with the CMCI storm settings when starting the timer whereas there's no need for that - if there's storm happening on this newly restarted cpu, we're going to be in normal CMCI mode initially and then when the CMCI interrupt starts firing, we're going to go to the polling mode with the timer real soon. Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Prarit Bhargava <prarit@redhat.com> Cc: Tony Luck <tony.luck@intel.com> Reviewed-by: Chen, Gong <gong.chen@linux.intel.com> Link: http://lkml.kernel.org/r/1387722156-5511-1-git-send-email-prarit@redhat.com
Diffstat (limited to 'drivers/acpi/resource.c')
0 files changed, 0 insertions, 0 deletions