[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130626203639.GM20274@pd.tnic>
Date: Wed, 26 Jun 2013 22:36:39 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chen Gong <gong.chen@...ux.intel.com>,
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Subject: Re: [PATCH] x86/mce: Update MCE severity condition check
On Wed, Jun 26, 2013 at 08:23:47PM +0000, Luck, Tony wrote:
> MCESEV(
> > - KEEP, "HT thread notices Action required: data load error",
> > - SER, MASK(MCI_STATUS_OVER|MCI_UC_SAR|MCI_ADDR|MCACOD, MCI_UC_SAR|MCI_ADDR|MCACOD_DATA),
> > - MCGMASK(MCG_STATUS_EIPV, 0)
> > + KEEP, "Action required but unaffected thread is continuable",
> > + SER, MASK(MCI_STATUS_OVER|MCI_UC_SAR|MCI_ADDR|MCACOD, MCI_UC_SAR|MCI_ADDR),
>
> > Why did we lose MCACOD_DATA from the MASK above? Was this intentional?
>
>
> We used to have separate entries for "HT thread notices ... data load" and "HT thread notices ... instruction load"
> because the old SDM had a complex table calling out the bit settings for each type of recoverable machine check.
>
> Latest SDM simplifies the table making it clear that for every SRAR (software recoverable action required) error
> we'll have the same bits in MCG_STATUS (EIPV=0, RIPV=1) ... so we don't need to check for the MCACOD value.
> See attached snapshot of the new table.
And this obviously is the case for the hardware too, I assume, not only
the SDM?
--
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