[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151207232524.GK22248@pd.tnic>
Date: Tue, 8 Dec 2015 00:25:24 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Raj, Ashok" <ashok.raj@...el.com>
Cc: "Luck, Tony" <tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [Patch V2] x86, mce: Ensure offline CPU's don't participate in
mce rendezvous process.
On Mon, Dec 07, 2015 at 06:46:40PM -0500, Raj, Ashok wrote:
> On Mon, Dec 07, 2015 at 11:34:27PM +0100, Borislav Petkov wrote:
> >
> > Box logs below.
>
> Do you have the dmidecode strings to find which platform this is?
Is this enough or you want complete dmidecode dump?
DMI: Intel Corporation LH Pass/S4600LH...., BIOS SE5C600.86B.99.99.2050.043020121425 04/30/2012
> Not sure how the fix works.. since we excluded only the ones offline.
> So unless all online cpu's check in, the code should give you the old
> behavior.
Did you miss my statement in my previous mail where I said that the MCE
is being raised only on the cores of node 0?
> What does cat /proc/interrupts | grep MCE
Can't. Shell on the box is dead after the injection.
> In a system broadcasting, all cpu counts should be the same. Since we didn't
> increment the offline stats, if you were to bring the cpu up, it should be one
> less than other cpus...
See the logs at the end of my previous email. #MC gets raised - or at
least output from mce_panic() comes out only - on the cores of node 0.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
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