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

From: Ingo Molnar
Date: Tue Jan 13 2009 - 12:45:56 EST



* Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:

> Ingo Molnar wrote:
>
>>>> A far more useful design for handling MCE events would be to feed
>>>> them into printk logging.
>>> If there's ASCII logging it should be separate from normal printk.
>>
>> Well, why?
>
> Mostly because the problem is not a kernel issue. Especially large
> systems with a lot of memory can generate a lot of corrected events (one
> bit flips in DIMMs are not that uncommon) and it's not good to mix that
> all up into other kernel messages. It also makes it more clear that it's
> not a kernel problem, but a hardware problem. I've got feedback over the
> years that confirm this sight.

Is your argument that syslog is not suitable for the logging of hw events?

If that is your argument then the answer is to extend syslog with those
aspects, instead of widening the quirky /dev based mce ABIs to achieve
something similar.

If you think that it's suitable then that contradicts your point above.

> [...]
>
> None of the points above are real show stoppers for an ASCII interface,
> but I think with all of this above together considered it's not really
> an attractive change.
>
> I think what could be done is:
>
> - Investigate how to make the panic message more information without
> adding full decoders.
>
> - Implement the default panic timeout method
> described above to get automatic on disk logging in common cases.
>
> Would that address your concerns?

For me the main blocking point is that mcelog uses a quirky, binary
side-channel instead of using our main ASCII based logging abstraction
that we have in Linux: printk + syslog.

That is a high level argument, while most of your arguments are low level.
I dont think you can understand my argument if you concentrate on the low
level only.

We need to resolve this instead of expanding the broken /dev/mcelog
interface. If we expand the broken interface first then that removes all
the incentives to enhance the primary logging facility of Linux in this
area.

Anyway, this merge window has been very crowded in the x86 space already,
and the MCE topic is not particularly super-important to have right now
either, so lets skip it for this cycle so that we have more time to
cleanly work out these details.

Let me know if there are must-have fixes in it and we can cherry-pick it
over into x86/urgent.

Thanks,

Ingo
--
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/