Messages in this thread | | | Date | Tue, 13 Jan 2009 18:45:22 +0100 | From | Ingo Molnar <> | Subject | Re: x86/mce merge, integration hickup + crash, design thoughts |
| |
* Andi Kleen <ak@linux.intel.com> 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
| |