Date:	Tue, 11 Jan 2011 23:48:09 +0100
From:	Borislav Petkov <bp@...64.org>
To:	Mike Waychison <mikew@...gle.com>
Cc:	"mingo@...e.hu" <mingo@...e.hu>,
	"rdunlap@...otime.net" <rdunlap@...otime.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Duncan Laurie <dlaurie@...gle.com>
Subject: Re: [PATCH] x86: Add an option to disable decoding of MCE

On Tue, Jan 11, 2011 at 04:51:57PM -0500, Mike Waychison wrote:
> On Tue, Jan 11, 2011 at 12:49 PM, Borislav Petkov <bp@...64.org> wrote:
> > Ok, let me preface this with an even easier suggestion: Can you simply
> > not compile EDAC (which includes CONFIG_EDAC_DECODE_MCE) in your kernels
> > and the whole issue with decoding disappears simply because no module
> > registers as a decoder...?
> 
> The trouble here is that default_decode_mce() is still getting called
> no matter what :(  It didn't really cause problems until you added
> atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, &m) to
> machine_check_poll().

Yeah, I figured as much... after hitting send :(. Feel free to add my

Acked-by: Borislav Petkov <borislav.petkov@....com>

to your patch.

> > Right, and this means that you need to know all the memory controller
> > topologies of all the different architectures and also the SPD accessing
> > based on a board type could be a pain. One of the main reasons for
> > fleshing out MCE decoding in the kernel was to avoid needless trouble
> > like that.
> 
> It's not that painful for us.  Our firmware guys own this userland
> code :)  I can see it being a pain for others however.

Yeah, what we actually need is a chipset-agnostic way (ACPI maybe?)
of mapping chip selects to the actual DIMMs so all that above can be
avoided...

> Doing this all in userland does have it's upsides as well fwiw. For
> example, MC4 is usually kept around across a reset, which means
> that the firmware can pick it up when the system goes down due to a
> processor context corruption.

True, although not always reliable due to that context corruption. Tony
Luck is adding code for writing the error information to a persistent
storage _before_ you reset so on platforms with such a device you'll
be able to look at MC4 (or any of the MCE regs, for that matter) after
reset, which, I think, would make error analysis much more convenient.
See http://marc.info/?l=linux-arch&m=129356804427008&w=2.

> We rely on these libraries as well to decode egregious uncorrectable
> memory errors as well as bus errors (like hypertransport sync floods).

Yeah, I don't think error decoding would help, at least on AMD, with
uncorrectable errors causing syncflood. We might do something about it
though :).

> > I've
> > heard similar troubles reported by other big server farm people and
> > what I'm currently working on is a RAS daemon that hooks into perf thus
> > enabling persistent performance events. This way, you could open a
> > debugfs file (this'll move to sysfs someday) and read the same decoded
> > data by mmaping the perf ringbuffer.
> 
> I'll definitely keep an eye out for your developments with RAS :)

Cool, I think I have the bulk of your requirements now, from your and
Duncan's mails. I'm always open for other suggestions too.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
--
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