[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikS9ocvQm2WK_9PFeiMNCcBGeW-8o1r30nnb59Y@mail.gmail.com>
Date: Tue, 15 Jun 2010 15:33:51 -0700
From: Tony Luck <tony.luck@...el.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Doug Thompson <norsk5@...oo.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Nils Carlson <nils.carlson@...d.ltu.se>,
Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...64.org>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
BrentYoung <brent.young@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"bluesmoke-devel@...ts.sourceforge.net"
<bluesmoke-devel@...ts.sourceforge.net>,
Doug Thompson <dougthompson@...ssion.com>,
Joe Perches <joe@...ches.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Edac Mailing List <linux-edac@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: Hardware Error Kernel Mini-Summit
On Mon, Jun 14, 2010 at 11:56 PM, Andi Kleen <andi@...stfloor.org> wrote:
> The way I envision it to working is that a abstracted dimm interface
> (or edac2 or whatever you want to call it) can be fed from any reasonable
> DIMM layout driver. This could be either DMI on x86 or some other
> driver. There would be nothing really x86 specific about that.
You could go one stage further and make DIMMs just one example of
a field replaceable unit. So the "error analysis subsystem" would keep track
of errors reported by any component (cpu, DIMM, I/O card, fan, power
supply, disk, ...). Each category could have different "X errors per Y
interval" parameter that made sense for it.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists