mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	"ananth@in.ibm.com" <ananth@in.ibm.com>,
	"masbock@linux.vnet.ibm.com" <masbock@linux.vnet.ibm.com>,
	"lcm@linux.vnet.ibm.com" <lcm@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"Huang, Ying" <ying.huang@intel.com>
Subject: Re: [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff mode for corrected errors
Date: Wed, 19 Jun 2013 22:14:38 +0200	[thread overview]
Message-ID: <20130619201438.GM28300@pd.tnic> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F2DA881C2@ORSMSX106.amr.corp.intel.com>

On Wed, Jun 19, 2013 at 07:05:16PM +0000, Luck, Tony wrote:
> > Why, fill out struct mce and do mce_log(mce) does not suffice?
> 
> There is (or should be)

Ha!

> a lot more interesting stuff in the CPER than just the address. Stuff
> that we don't have fields for in the existing mcelog structure. We
> also need to treat filtered records from modern APEI implementations a
> bit differently from the old stuff.

Great, the CPER record is described in the UEFI spec. Those BIOS people
are all like a mafia.

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.

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.

> The original user of this code was Westmere-EX, which used it as a
> workaround for a missing address in MCi_ADDR for corrected errors.
> So in that scenario we had every error being reported and mcelog(8)
> deamon doing the threshold analysis to decide when to take action.
>
> 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?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2013-06-19 20:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 17:57 [PATCH v2 1/2] mce: acpi/apei: Honour Firmware First for MCA banks listed in APEI HEST CMC Naveen N. Rao
2013-06-19 17:57 ` [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff mode for corrected errors Naveen N. Rao
2013-06-19 18:04   ` Borislav Petkov
2013-06-19 18:17     ` Naveen N. Rao
2013-06-19 18:19     ` Luck, Tony
2013-06-19 18:36       ` Borislav Petkov
2013-06-19 19:05         ` Luck, Tony
2013-06-19 20:14           ` Borislav Petkov [this message]
2013-06-19 20:33             ` Luck, Tony
2013-06-19 21:07               ` Borislav Petkov
2013-06-19 21:28                 ` Luck, Tony
2013-06-19 21:41                   ` Borislav Petkov
2013-06-19 22:08                     ` Luck, Tony
2013-06-20  5:35                       ` Borislav Petkov
2013-06-20 21:21                   ` Naveen N. Rao
2013-06-20 22:11                     ` Luck, Tony
2013-06-21  7:27                       ` Borislav Petkov
2013-06-21 16:43                         ` Naveen N. Rao
2013-06-28 12:04                         ` Naveen N. Rao
2013-06-28 17:31                           ` Tony Luck
2013-07-01 15:07                             ` Naveen N. Rao
2013-07-01 15:38                               ` Borislav Petkov
2013-07-01 15:41                                 ` Naveen N. Rao
2013-06-20  7:48   ` Borislav Petkov
2013-06-20 19:02     ` Naveen N. Rao
2013-06-20  7:39 ` [PATCH v2 1/2] mce: acpi/apei: Honour Firmware First for MCA banks listed in APEI HEST CMC Borislav Petkov
2013-06-20 19:08   ` Naveen N. Rao
2013-06-20 19:29     ` Borislav Petkov
2013-06-20 20:14       ` Naveen N. Rao
2013-06-20 20:57         ` Borislav Petkov
2013-06-20 21:22           ` Naveen N. Rao
2013-06-21  7:34             ` Borislav Petkov
2013-06-21  7:46               ` Naveen N. Rao
2013-06-21  8:36                 ` Borislav Petkov
2013-06-21  9:32                   ` Naveen N. Rao
2013-06-21 14:08                     ` Borislav Petkov
2013-06-21 16:47                   ` Tony Luck
2013-06-21 17:40                     ` Borislav Petkov
2013-06-25 17:46                       ` Naveen N. Rao
2013-06-25 17:53                         ` Borislav Petkov
2013-06-25 17:55                         ` Luck, Tony
2013-06-25 18:28                           ` Naveen N. Rao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130619201438.GM28300@pd.tnic \
    --to=bp@alien8.de \
    --cc=ananth@in.ibm.com \
    --cc=lcm@linux.vnet.ibm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masbock@linux.vnet.ibm.com \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®