From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>,
Andi Kleen <andi@firstfloor.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-tip-commits@vger.kernel.org,
Doug Thompson <dougthompson@xmission.com>
Subject: Re: [tip:x86/mce] x86, mce: Make xeon75xx memory driver dependent on PCI
Date: Fri, 19 Feb 2010 13:17:50 -0200 [thread overview]
Message-ID: <4B7EAB9E.2010509@redhat.com> (raw)
In-Reply-To: <4B7E906D.8050501@linux.intel.com>
Andi,
Andi Kleen wrote:
> Borislav,
>>>> year. You are refusing to work with other people on a well designed
>>
>> Sorry, but from our last discussion on attempting to work towards such
>> an infrastructure solution I got the same impression as Thomas and Ingo
>> that you're simply not willing to work together on getting a real thing
>> done. That's why I stopped bothering - it simply made no sense to me to
>> waste time in fruitless discussions.
>
> Well I keep ignoring suggestions to put more stuff into EDAC,
> mostly because I think the EDAC design needs to be thrown out
> instead of extended. Are you referring to that?
>
> My impression was that you got to the same conclusion (at least
> for parts of current EDAC like the events) based on your earlier emails.
>
> The current issue is less in enumeration/topology anyways but more
> in event handling I would say. In the end topology/enumeration is
> the easier part, and most of it is already working quite well.
>
> I'm trying to do things step by step, including for short term
> problems extending current interfaces if possible and then longer
> term moving to new better interfaces.
Ingo and Thomas are right: we need to work together to improve the
error report, and this means that we shouldn't ignore putting more stuff
in EDAC.
EDAC is generic enough to work with different type of memory and memory
controllers, and to provide a consistent interface to describe it on a way
that userspace doesn't need to know what are the error registers at
the hardware, nor how to decode a "magic" error number into something
that has a meaning.
As Boris properly pointed, EDAC has space for improvements, and part of
the perf logic can be used as a start point to give some flash new ideas.
The main issue I see with MCE is at the interface level. I think if we
all cope together, we can converge into a proper interface that will
be accepted upstream.
--
Cheers,
Mauro
next prev parent reply other threads:[~2010-02-19 15:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 22:17 [PATCH] x86: mce: Xeon75xx specific interface to get corrected memory error information Andi Kleen
2010-01-22 10:51 ` [tip:x86/mce] x86, " tip-bot for Andi Kleen
2010-01-22 10:51 ` [tip:x86/mce] x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll tip-bot for H. Peter Anvin
2010-01-23 5:17 ` Ingo Molnar
2010-01-23 7:58 ` Borislav Petkov
2010-01-23 9:00 ` Ingo Molnar
2010-01-24 10:08 ` Borislav Petkov
2010-01-25 13:19 ` Andi Kleen
2010-01-26 6:33 ` Borislav Petkov
2010-01-26 9:06 ` Hidetoshi Seto
2010-01-26 16:09 ` Andi Kleen
2010-01-26 15:36 ` Andi Kleen
2010-02-16 21:02 ` Ingo Molnar
2010-02-22 8:28 ` Borislav Petkov
2010-02-22 9:47 ` Ingo Molnar
2010-02-22 11:59 ` Mauro Carvalho Chehab
2010-02-24 17:42 ` Mauro Carvalho Chehab
2010-02-24 20:28 ` Andi Kleen
2010-01-27 12:34 ` Mauro Carvalho Chehab
2010-01-27 14:39 ` Andi Kleen
2010-01-27 15:04 ` Mauro Carvalho Chehab
2010-01-27 16:36 ` Andi Kleen
2010-01-23 11:33 ` Andi Kleen
2010-02-05 23:31 ` [tip:x86/mce] x86, mce: Make xeon75xx memory driver dependent on PCI tip-bot for Andi Kleen
2010-02-16 20:47 ` Ingo Molnar
2010-02-16 22:29 ` Andi Kleen
2010-02-19 10:50 ` Thomas Gleixner
2010-02-19 12:17 ` Andi Kleen
2010-02-19 12:45 ` Borislav Petkov
2010-02-19 13:21 ` Andi Kleen
2010-02-19 15:17 ` Mauro Carvalho Chehab [this message]
2010-02-19 15:37 ` Andi Kleen
2010-02-20 0:14 ` Mauro Carvalho Chehab
2010-02-20 9:01 ` Andi Kleen
2010-02-19 15:46 ` Thomas Gleixner
2010-02-22 7:38 ` Hidetoshi Seto
[not found] <211660974.2010861266660371958.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2010-02-20 10:14 ` Mauro Carvalho Chehab
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=4B7EAB9E.2010509@redhat.com \
--to=mchehab@redhat.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=borislav.petkov@amd.com \
--cc=dougthompson@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).