Re: x86/mce merge, integration hickup + crash, design thoughts

[Andi Kleen <ak@linux.intel.com>]

Russ Anderson wrote:

> Summary ASCII information is useful, especially if the error
> is clearly a hardware error.  Andi is right that decoding the
> information to print the specific failing hardware (ie which 
> DIMM) may be too dificult to decode on the way down.  It would
> be great to identify the failing hardware component on the
> way down, when possible.

This will hopefully happen in the future. In fact mcelog has support
to decode using DMI tables, but it turns out this doesn't work
very well in practice (both because of BIOS problems and because
the DMI standard was not really designed for this). That is why
I wouldn't advocate right now to move this code from mcelog
into the kernel. This might change later.


>>> It turns out that users don't really find this more enlightening (most 
>>> users have no clue what a Northbridge is).  They think it's some kind of 
>>> kernel bug even with the HARDWARE ERROR header.
>> You should not assume that administrators/users reading kernel crash 
>> messages are dumb. (an ordinary user wont see it most of the time anyway) 
>>
>> The usage patterns i see is that admins who get an MCE crash often fail to 
>> write down the whole MCE message (not realizing that it is important) and 
>> have to go back and reproduce the MCE crash once again before they can get 
>> any meaningful information.
> 
> This is why saving the error records to MVRAM is so useful.
> After reboot the records can be read, formatted, and logged.

I've been looking at using EFI runtime services for this, but it's
also somewhat problematic (e.g. getting the messages out again in
a useful way without risking duplicating events)

There are also a few other candidates like the Management Engine
interface on many Intel platforms, but it's also not available everywhere.

Short term just changing the MCE panic to timeout by default
is the best option. I'll probably submit that for .30

-Andi