public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	ying.huang@intel.com
Subject: Re: x86/mce merge, integration hickup + crash, design thoughts
Date: Tue, 13 Jan 2009 18:45:22 +0100	[thread overview]
Message-ID: <20090113174522.GA26965@elte.hu> (raw)
In-Reply-To: <49594411.60000@linux.intel.com>


* 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

  reply	other threads:[~2009-01-13 17:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-27 15:50 x86/mce merge, integration hickup + crash, design thoughts Ingo Molnar
2008-12-27 22:51 ` Ingo Molnar
2008-12-29 21:41   ` Andi Kleen
2009-01-13 17:45     ` Ingo Molnar [this message]
2009-01-13 18:57       ` Tim Hockin
2009-01-14  9:29         ` Andi Kleen
2009-01-14 16:18           ` Tim Hockin
2009-01-14 18:05             ` Andi Kleen
2009-01-14 19:32               ` Tim Hockin
2009-01-15 22:56                 ` Andi Kleen
2009-01-15 23:39                   ` Tim Hockin
2009-01-14  2:02       ` Huang Ying
2008-12-30 21:13   ` Russ Anderson
2008-12-31 13:32     ` Andi Kleen
2008-12-31 18:09       ` Russ Anderson
2008-12-29 21:51 ` Andi Kleen
2008-12-30  6:50   ` Ingo Molnar
2008-12-30  9:13     ` Andi Kleen
2008-12-30 21:29 ` Russ Anderson
2009-01-12 22:02 ` Tim Hockin
2009-01-13  5:02   ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090113174522.GA26965@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox