Re: [tip:x86/mce] x86, mce: Rename cpu_specific_poll tomce_cpu_specific_poll

[Andi Kleen]

Hi,

> Because this is one thing that has been bugging us for a long time. We
> don't have a centralized smart utility with lots of small subcommands
> like perf or git, if you like, which can dump you the whole or parts

PC configuration is all in dmidecode, CPU/node information in lscpu
these days (part of utils-linux)

The dmidecode information could be perhaps presented nicer, but 
I don't think we need any fundamental new tools.

> 1. We need to notify userspace, as you've said earlier, and not scan
> the syslog all the time. And EDAC, although decoding the correctable

mcelog never scanned the syslog all the time. This is just
EDAC misdesign.

But yes syslog is exactly the wrong interface for these kinds of errors.

> 2. Also another very good point you had is go into maintenance mode by
> throttling or even suspend all uspace processes and start a restricted
> maintenance shell after an MCE happens. This should be done based on the

When you have a unrecoverable MCE this is not safe because you
can't write anything to disk (and usually the system is unstable
and will crash soon) because there are uncontained errors somewhere
in the hardware. The most important thing to do in this situation
is to *NOT* write anything to disk (and that is the reason
why the hardware raised the unrecoverable MCE in the first place)
Having a shell without being able to write to disk doesn't make sense.

When you have a recoverable MCE with contained errors this is not needed, 
because it, well, just recovers.

> 3. All the hw events like correctable ECCs should be thresholded so that
> all errors exceeding a preset threshold (below that is normal operation

Agreed. Corrected errors without thresholds are useless (that is one 
of the main reasons why syslog is a bad idea for them)

See also my plumbers presentation on the topic:

http://halobates.de/plumbers-error.pdf

One key part is that for most interesting reactions to thresholds
you need user space, kernel space is too limited.

My current direction was implementing this in mcelog which
maintains threshold counters and already does a couple of direct (user 
based) threshold reactions, like offlining cores and pages and reporting
short user friendly error summaries when thresholds are exceeded.

Longer term I hope to move to a more generic (user) error infrastructure
that handles more kinds of errors. This needs some infrastructure
work, but not too much.

> 
> The current decoding needs more loving too since now it says something
> like the following:

Yes, see the slide set above on thoughts how a good error looks like.

The big problem with EDAC currently is that it neither gives
the information actually needed (like mainboard labels), but gives
a lot of irrelevant low level information. And since it's kernel
based it cannot do most of the interesting reactions. And it doesn't
have a usable interface to add user events.

And yes having all that crap in syslog is completely useless, unless
you're debugging code.

-Andi

-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/