aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/kernel/cpu/transmeta.c
diff options
context:
space:
mode:
authorIngo Molnar <mingo@elte.hu>2009-08-17 10:19:00 +0200
committerIngo Molnar <mingo@elte.hu>2009-08-17 13:28:25 +0200
commite412cd257e0d51e0ecbb89f50953835b5a0681b2 (patch)
tree42b67c3a392511b4d2b2e6fc05008566246dc35b /arch/x86/kernel/cpu/transmeta.c
parentc7f6fa44115d401e89db730f357629d39f8e4ba6 (diff)
x86, mce: Don't initialize MCEs on unknown CPUs
An older test-box started hanging at the following point during bootup: [ 0.022996] Mount-cache hash table entries: 512 [ 0.024996] Initializing cgroup subsys debug [ 0.025996] Initializing cgroup subsys cpuacct [ 0.026995] Initializing cgroup subsys devices [ 0.027995] Initializing cgroup subsys freezer [ 0.028995] mce: CPU supports 5 MCE banks I've bisected it down to commit 4efc0670 ("x86, mce: use 64bit machine check code on 32bit"), which utilizes the MCE code on 32-bit systems too. The problem is caused by this detail in my config: # CONFIG_CPU_SUP_INTEL is not set This disables the quirks in mce_cpu_quirks() but still enables MCE support - which then hangs due to the missing quirk workaround needed on this CPU: if (c->x86 == 6 && c->x86_model < 0x1A && banks > 0) mce_banks[0].init = 0; The safe solution is to not initialize MCEs if we dont know on what CPU we are running (or if that CPU's support code got disabled in the config). Also be a bit more defensive on 32-bit systems: dont do a boot-time dump of pending MCEs not just on the specific system that we found a problem with (Pentium-M), but earlier ones as well. Now this problem is probably not common and disabling CPU support is rare - but still being more defensive in something we turned on for a wide range of CPUs is prudent. Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> LKML-Reference: Message-ID: <4A88E3E4.40506@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch/x86/kernel/cpu/transmeta.c')
0 files changed, 0 insertions, 0 deletions