From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Andi Kleen <ak@linux.intel.com>,
Borislav Petkov <borislav.petkov@amd.com>,
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: Sat, 20 Feb 2010 05:14:50 -0500 (EST) [thread overview]
Message-ID: <1919069044.2010911266660890495.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <211660974.2010861266660371958.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
----- "Andi Kleen" <andi@firstfloor.org> escreveu:
> On Fri, Feb 19, 2010 at 10:14:17PM -0200, Mauro Carvalho Chehab
> wrote:
>
> Mauro,
>
> > I was thinking on a way where we could work with the EDAC/MCE
> issues, and
> > a way for us to move ahead. My proposal is to organize an EDAC/MCE
> BoF session
> > or a mini-summit during the Collaboration Summit, in San Francisco,
> with
> > the interested parties. I suspect that some of us will be there
> already.
>
> I didn't plan to be there so far. A BoF is probably a good idea,
> and also looking closely at EDAC together,
> but it would be better at some more kernel focussed conference.
>
> If everyone else is at that summit I can try to come,
> but it would be likely difficult.
I'm proposing the Collaboration Summit due to its date: it will
happen in April. The next Kernel conf will be on a longer time.
> We could probably do some kind of online BoF shorter time
> (e.g. using some chat setup or on the phone)
We may try to do some discussions via chat before it, but I still
think that having we all at the same room with some whiteboard
will better work.
> > It shouldn't be hard to find some place there for us to take a look
> at the
> > EDAC architecture and come with some proposal.
>
> Proposal for what exactly?
>
> Is this for a event interface or for a topology interface or both
> or something else entirely?
We should define the topics. I think we should discuss both topics.
I agree that the better is to represent the hardware per FRU. So,
maybe we can find a better topology representation.
> My personal plan so far was to work on the APEI interface
> and then possibly look at migrating MCE to that infrastructure too,
> while updating mcelog to talk to it. This would be mostly
> addressing events so far.
The better is to have some discussions before using APEI or any other
interface for it. It should be considered that the hardware errors
should be presented on a consistent way not only for newer processors
and memory controllers, but also for the already supported ones.
> > As today is the last day for CFP, I've also submitted there a
> proposal for a
> > panel. If approved, we can use it to collect data from hardware
> error users
> > (sysops and other users that require high availability on their
> services),
> > for us to discuss some strategies to address the issue or to
> summarize what
> > will be discussed on the event.
>
> You want to collect error rates or want to collect use cases?
>
> For a serious collection doing it online would probably
> give better coverage.
>
> I do both to some degree already.
Both data collect are important (and I also do it to some degree),
and we can do it via other means, but a face-to-face meeting may
help to vallidate any ideas we may have about improvements/changes
at the interfaces and features.
If we succeed on such discussions at the planning phase, this will
save us a lot of development time and will help to have an easier
upstream adoption.
So, I think it is a worthy try.
Cheers,
Mauro
next parent reply other threads:[~2010-02-20 10:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <211660974.2010861266660371958.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2010-02-20 10:14 ` Mauro Carvalho Chehab [this message]
2010-01-23 11:33 [tip:x86/mce] x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll 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
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
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=1919069044.2010911266660890495.JavaMail.root@zmail05.collab.prod.int.phx2.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).