[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A893A14.1070103@linux.intel.com>
Date: Mon, 17 Aug 2009 13:08:04 +0200
From: Andi Kleen <ak@...ux.intel.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
tglx@...utronix.de, Yinghai Lu <yinghai@...nel.org>,
Huang Ying <ying.huang@...el.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
linux-tip-commits@...r.kernel.org
Subject: Re: [boot crash] Re: [tip:x86/mce3] x86, mce: use 64bit machine check
code on 32bit
Ingo Molnar wrote:
> * Hidetoshi Seto <seto.hidetoshi@...fujitsu.com> wrote:
>
>> One possibility is: if the BIOS doesn't clear status in banks, new
>> mce codes will try to log such junks. If the junk is totally junk
>> but can be decoded as a valid log with MISCV or ADDRV bit, and if
>> the cpu try to access register which is not implemented (e.g.
>> IA32_MCi_MISC/ADDR), then such access might cause a general
>> protection exception. (ref. ASDM 3A 15.3.2.3)
>
> btw., that reminds me: mce_rdmsrl() needs to be fixed to use
> rdmsrl_safe() and it should emit a WARN_ONCE() if it ever hits an
> error while trying to access registers.
In general systems (like VMs) who don't have MCA MSRs don't declare the
capability bits (there are own capability bits for all of this) and then
the MSRs are never touched. So far I've not had a
single report of this going wrong.
I suspect the problem on your system is something else too we just
need to debug properly.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists