linux-kernel - Re: [PATCH] RAS: Add a tracepoint for reporting memory controller events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120601232818.GH30418@aftab.osrc.amd.com>
Date:	Sat, 2 Jun 2012 01:28:18 +0200
From:	Borislav Petkov <bp@...64.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Borislav Petkov <bp@...64.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aristeu Rozanski <arozansk@...hat.com>,
	Doug Thompson <norsk5@...oo.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	"Chen, Gong" <gong.chen@...el.com>
Subject: Re: [PATCH] RAS: Add a tracepoint for reporting memory controller
 events

On Fri, Jun 01, 2012 at 11:19:17PM +0000, Luck, Tony wrote:
> > Uuh, that doesn't sound good. Can't you guys make the CMCI run on one
> > CPU only? I mean, it is a single CECC, no need to stop all cores on the
> > socket for it, right?
> >
> > Arguably, it'll be best if the core that sees the CECC fires the CMCI
> > too and the others continue on their merry way.
> 
> That would be best ... but life is more complicated. We can get CMCI for
> some processor errors where the error will be logged in a per-core bank,
> but for some reason it is hard to have just the threads on that core see
> the CMCI. So we just use a shotgun to blast everything standing in the
> general direction of the error - so that the one (or two) cpus that can
> actually see the error will get the message.  In the normal case when
> there is a very low rate of errors, this doesn't do much harm. But it makes
> the storm situation when there are many errors a whole lot worse (20x
> worse for Westmere with 10 cores * 2 threads).

Ok, this explains the whole deal behind throttling the CMCI and
temporarily polling the MCA registers.

This explanation could very well go into the commit message when you
guys are done testing the patch from tglx.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/