[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F2DA8838B@ORSMSX106.amr.corp.intel.com>
Date: Wed, 19 Jun 2013 20:33:49 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
"ananth@...ibm.com" <ananth@...ibm.com>,
"masbock@...ux.vnet.ibm.com" <masbock@...ux.vnet.ibm.com>,
"lcm@...ux.vnet.ibm.com" <lcm@...ux.vnet.ibm.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"Huang, Ying" <ying.huang@...el.com>
Subject: RE: [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff
mode for corrected errors
>> There is (or should be)
>
> Ha!
Oh ye of little faith - I'm sure the BIOS will get this right this time :-)
> Ok, seriously: so the situation should still be fine, FF reported errors
> get the CPER format while the rest, the "old" MCE format.
>
> cper.c is doing printk so I'm guessing it would need to get its own
> tracepoint and carry that to userspace.
Yes - a tracepoint is the right answer here for all the new stuff.
> Concerning the RAS daemon, Robert and I are making good progress so once
> we have the persistent events in perf, we can read that tracepoint in
> userspace and do whatever we want with the error info.
Mauro has a rasdaemon in progress
git://git.fedorahosted.org/rasdaemon.git
just picks up perf/events and logs to a sqlite database.
>> In this new modern world - Naveen wants to have the BIOS decide the
>> threshold, so we'd like Linux to take some action as soon as it sees
>> just one CPER.
>
> Why would Linux have to intervene if it is doing FF - wasn't the deal
> behind Firmware First for the firmware to get the error first and handle
> accordingly?
Because Linux can do runtime things that the BIOS can't - like offline a 4K page.
Idea here is that BIOS does whatever the OEM thinks is the right level of
threshholding - not bothering the OS with petty details of random corrected
erorrs that mean nothing. But if there is some repeated error (like a stuck bit)
then the BIOS can provide a CPER to the OS telling it that it would be a good idea
to stop using that page.
And this is where the semantics of a CPER change between the original WSM-EX
implementation ... where Linux expects to see all the errors and do its own
thresholding only taking a page offline if it sees a lot of CPER refer to the same
page; and now - where the BIOS does the counting and tells Linux just once to
take the page offline.
-Tony
Powered by blists - more mailing lists