From: Borislav Petkov <bp@alien8.de>
To: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
tony.luck@intel.com, dougthompson@xmission.com,
mchehab@osg.samsung.com, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
dave.hansen@linux.intel.com, mgorman@suse.de, bp@suse.de,
riel@redhat.com, jacob.w.shin@gmail.com
Subject: Re: [PATCH 0/3] Fix MCE handling for AMD multi-node processors
Date: Tue, 23 Dec 2014 00:19:29 +0100 [thread overview]
Message-ID: <20141222231929.GC1942@pd.tnic> (raw)
In-Reply-To: <5498858F.1030209@amd.com>
On Mon, Dec 22, 2014 at 02:56:47PM -0600, Aravind Gopalakrishnan wrote:
> On 12/22/2014 2:15 PM, Borislav Petkov wrote:
> >On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan wrote:
> >>When a MCE happens that is to be logged onto bank 4 of AMD multi-node
> >>processors, they are reported only to corresponding node base core of
> >>the cpu on which the error occurred.
> >>
> >>Refer D18F3x44[NbMcaToMstCpuEn] on BKDGs of Fam10h and later for
> >Let me try to understand this correctly:
> >
> >Does that mean that we could fix this by simply doing:
> >
> >D18F3x44[NbMcaToMstCpuEn]=0b
> >
> >on each NB?
> >
>
> Not quite..
> When this field is 0, BKDG says the error may be reported to the core that
> originated the request *if applicable and known*
> Looking at the error signatures table for MC4 (Part 2),
> we can see only some errors have 'ErrCoreId' column as valid
>
> Besides, if IO originated the request, then it is reported only to NBC.
>
> So, to take care of all these cases, I am just following one approach here:
> and that is to look at NBC MSRs for any bank 4 errors.
> (It seems to be what the BKDG recommends anyway as BIOS by default should
> set D18F3x44[NbMcaToMstCpuEn])
Then in that case you have to check the case where
D18F3x44[NbMcaToMstCpuEn] is 0 for whatever reason (some BIOS forgot to
set it or whatever) and to set it again.
Then, upon a quick scan, your patches are adding a lot of vendor-specific
stuff which doesn't belong in the #MC handler, should probably be
wrapped or so, no good idea right now.
Then, you're using rd/wrmsr_on_cpu which does smp_call_function_single()
which can deadlock in atomic context and #MC is one.
Also, the math in amd_get_nbc_for_node() is too fragile and will break
the moment some BIOS renumbers cores to accomodate some other OS.
In any case, I won't be able to take a detailed look soon with the
holidays coming up.
Also, I'm wondering if this can't be solved much more elegantly
by detecting that condition (bank == 4) in the #MC handler and
issuing an IPI before exiting it using irq_work which will schedule
do_machine_check on the NBC. And that should be even easier to do since
we're moving the #MC handler out of the IST and to the normal kernel
stack for 3.20, which would make this endeavor pretty cheap.
Anyway, just a couple of thoughts...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-12-22 23:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 20:10 [PATCH 0/3] Fix MCE handling for AMD multi-node processors Aravind Gopalakrishnan
2014-12-22 20:10 ` [PATCH 1/3] x86,amd: Refactor amd cpu topology functions for " Aravind Gopalakrishnan
2014-12-22 20:10 ` [PATCH 2/3] x86, mce: Handle AMD MCE on bank4 on NBC " Aravind Gopalakrishnan
2014-12-22 20:10 ` [PATCH 3/3] edac, mce_amd_inj: Inject errors only on NBC for bank 4 errors Aravind Gopalakrishnan
2014-12-22 20:15 ` [PATCH 0/3] Fix MCE handling for AMD multi-node processors Borislav Petkov
2014-12-22 20:56 ` Aravind Gopalakrishnan
2014-12-22 23:19 ` Borislav Petkov [this message]
2014-12-23 19:41 ` Aravind Gopalakrishnan
2015-01-06 23:54 ` Aravind Gopalakrishnan
2015-01-07 17:06 ` Borislav Petkov
2015-01-08 0:18 ` Aravind Gopalakrishnan
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=20141222231929.GC1942@pd.tnic \
--to=bp@alien8.de \
--cc=aravind.gopalakrishnan@amd.com \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=dougthompson@xmission.com \
--cc=hpa@zytor.com \
--cc=jacob.w.shin@gmail.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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.