All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yucong <slaoub@gmail.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "bp@alien8.de" <bp@alien8.de>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"aravind.gopalakrishnan@amd.com" <aravind.gopalakrishnan@amd.com>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] x86, mce: support memory error recovery for both UCNA and Deferred error in machine_check_poll
Date: Tue, 28 Oct 2014 10:21:27 +0800	[thread overview]
Message-ID: <1414462887.20336.10.camel@debian> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32917841@ORSMSX114.amr.corp.intel.com>

On Mon, 2014-10-27 at 23:10 +0000, Luck, Tony wrote:
> +	m->mcgstatus |= (MCG_STATUS_MCIP|MCG_STATUS_RIPV);
> +	severity = mce_severity(m, mca_cfg.tolerant, NULL);
> 
> This seems a big hack to make mce_severity() work when called from
> CMCI context (when MCG_STATUS register is not set).  It would also
> be confusing as the subsequent logged entries would show MCIP and RIPV
> bits set in the mcg_status.
> 
In fact, I have already noticed this issue from the start. But the 
Intel SDM document that MCIP/RIPV/EIPV are specific to machine check
exception. And I don't know if the above flag bits will be checked in
CMCI context by error log/decode handlers. 

> If someone can think of a less hacky way to do this, that would be good. Otherwise
> the code needs a comment, and should reset m->mcg_status to avoid making logs
> that have incorrect data.
> 
Yes! the above code snippet should be commented. And another method 
that can be used for restoring m->mcgstatus is shown below.

+        u8 mcgs = m->mcgstatus & 0xff;
+
+        m->mcgstatus |= (MCG_STATUS_MCIP|MCG_STATUS_RIPV);
+        severity = mce_severity(m, mca_cfg.tolerant, NULL);
+        m->mcgstatus = (m->mcgstatus & ~0xff) | mcgs;

thx!
cyc


  reply	other threads:[~2014-10-28  2:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27  0:56 [PATCH 0/2] RAS: add the support for handling UCNA/DEFERRED error Chen Yucong
2014-10-27  0:56 ` [PATCH 1/2] x86, mce, severity: extend the the mce_severity mechanism to handle " Chen Yucong
2014-10-27  0:56 ` [PATCH 2/2] x86, mce: support memory error recovery for both UCNA and Deferred error in machine_check_poll Chen Yucong
2014-10-27 23:10   ` Luck, Tony
2014-10-28  2:21     ` Chen Yucong [this message]
2014-10-29  2:16     ` Chen Yucong
2014-11-04  2:11       ` Chen Yucong
2014-11-04 11:38       ` Borislav Petkov
2014-10-27  9:36 ` [PATCH 0/2] RAS: add the support for handling UCNA/DEFERRED error Chen Yucong

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=1414462887.20336.10.camel@debian \
    --to=slaoub@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.