[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130619214145.GS28300@pd.tnic>
Date: Wed, 19 Jun 2013 23:41:45 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
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>,
Robert Richter <rric@...nel.org>
Subject: Re: [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff
mode for corrected errors
On Wed, Jun 19, 2013 at 09:28:50PM +0000, Luck, Tony wrote:
> > Ok, where is that semantics? What in a CPER record does say "this error
> > should tell you that you need to offline the containing page and I'm
> > telling you this exactly only once"? Error Severity 0, i.e. Recoverable?
>
> Naveen - this one is for you (or for your BIOS team). Can you get us a sample
> CPER that you plan to provide when the BIOS decides that its threshold has
> been exceeded? How will it be different from what old WSM-EX platforms
> were sending to us? Hopefully the answer is encoded in the CPER record
> and not in some code we have to put in Linux to say "if (IBMplatform) do_thing_1(); else ... "
If we're going to be vendor-specific (which I'm pretty sure we will),
we'd gonna have to export knobs to userspace which each vendor can tweak
for themselves. Otherwise we'd get the DMI quirks ugliness all over
again and we better nip it in the bud, while we can.
> > Ok, we're talking about the S in RAS now. Do we have error recovery
> > strategies specified anywhere? Are they per-platform or generic? Is this
> > CPER strategy above, for example, only valid for some platforms or for
> > all APEI-using hardware?
>
> mcelog(8) daemon has been doing this for years ... but it used the "predictive
> failure analysis" buzzwords that were popular way back then (today the
> marketing people seem to prefer "self healing" ). Whatever the name, the
> concept is the same ... take some set of corrected event reports and infer
> from them that something worse may happen soon, and use that information
> to try to avoid the (possibly) impending crash.
Ok, so some sort of userspace is enforcing policy based on collected
data/heuristics.
The above question about what to do *without* going to userspace and
back is maybe more interesting and we'd need a clean design there...
we'll see.
> > Questions over questions...
>
> Questions are good - they help fill out gaps
I know - that's why I'm trying to poke holes early...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
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