Date: Sat, 10 Feb 2007 13:48:53 +0000
From: Alan <alan@lxorguk.ukuu.org.uk>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: -mm merge plans for 2.6.21
Message-ID: <20070210134853.5ab6c211@localhost.localdomain>
In-Reply-To: <p73ps8igo0v.fsf@bingen.suse.de>
References: <20070208150710.1324f6b4.akpm@linux-foundation.org>
	<20070209193753.76bc2430@localhost.localdomain>
	<p73ps8igo0v.fsf@bingen.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1302
Lines: 29

> Well it's a technical issue -- it conflicts with the machine check
> code that is already implemented by stealing away its events.
> You would first need a CONFIG_MCE=n on x86-64 at least, otherwise
> one of them will be unhappy.

That is a fair point, albeit after far too long sitting stuck in the tree.
I'll have a look into this a bit further, probably MCE_K8 should feed off
the output of the MCE driver.

> The other issue is that the existing code does everything EDAC
> K8 does already perfectly fine, just in a small fraction of 
> the code.

Which is false. It provided a totally inconsistent interface to user
space, while the EDAC layer provides the consistency many people need and
want. Also unless it has changed remarkably the MCE driver doesn't do
scrubbing which is needed in software on some chip revisions.

The MCE driver is small, neat, incomplete for some cases and different
to all the other platforms as they use off CPU memory controllers. Its
ideal for a lot of uses but not big enterprise systems. Thats why we need
both.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/