[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F31CBCE72@ORSMSX106.amr.corp.intel.com>
Date: Thu, 15 Aug 2013 18:16:48 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>,
Mauro Carvalho Chehab <m.chehab@...sung.com>
CC: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"rjw@...k.pl" <rjw@...k.pl>,
"lance.ortiz@...com" <lance.ortiz@...com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Aristeu Rozanski Filho" <arozansk@...hat.com>
Subject: RE: [PATCH 3/3] mce: acpi/apei: trace: Enable ghes memory error
trace event
> * We parse some APEI table and disable those MCA banks which the BIOS
> wants to handle first.
We have no idea which errors the BIOS has chosen for itself. We just know which
bank numbers ... and Intel processors change mappings of which errors are logged
in which banks in every new processor tock (and sometimes tick). Some banks
are documented in processor datasheet. most are not. Most common case might
well be memory ... but it could be cache, or I/O, or ...
So this doesn't help Mauro figure out whether to allow loading of an
EDAC driver that will peek and poke at chipset specific registers in
possibly racy ways with BIOS code doing the same thing.
-Tony
Powered by blists - more mailing lists