From: Borislav Petkov <bp@alien8.de>
To: linux-edac <linux-edac@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Tony Luck <tony.luck@intel.com>
Subject: [PATCH 02/11] x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI
Date: Thu, 6 Apr 2017 11:06:25 +0200 [thread overview]
Message-ID: <20170406090634.30950-3-bp@alien8.de> (raw)
In-Reply-To: <20170406090634.30950-1-bp@alien8.de>
From: Borislav Petkov <bp@suse.de>
Apparently, some machines used to report DRAM errors through a PCI SERR
NMI. This is why we have a call into EDAC in the NMI handler. See
c0d121720220 ("drivers/edac: add new nmi rescan").
>From looking at the patch above, that's two drivers: e752x_edac.c and
e7xxx_edac.c. Now, I wanna say those are old machines which are probably
decommissioned already.
Tony says that "[t]the newest CPU supported by either of those drivers
is the Xeon E7520 (a.k.a. "Nehalem") released in Q1'2010. Possibly some
folks are still using these ... but people that hold onto h/w for 7
years generally cling to old s/w too ... so I'd guess it unlikely that
we will get complaints for breaking these in upstream."
So even if there is a small number still in use, we did load EDAC with
edac_op_state == EDAC_OPSTATE_POLL by default (we still do, in fact)
which means a default EDAC setup without any parameters supplied on the
command line or otherwise would never even log the error in the NMI
handler because we're polling by default:
inline int edac_handler_set(void)
{
if (edac_op_state == EDAC_OPSTATE_POLL)
return 0;
return atomic_read(&edac_handlers);
}
So, long story short, I'd like to get rid of that nastiness called
edac_stub.c and confine all the EDAC drivers solely to drivers/edac/. If
we ever have to do stuff like that again, it should be notifiers we're
using and not some insanity like this one.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Tony Luck <tony.luck@intel.com>
---
arch/x86/kernel/nmi.c | 11 -----------
drivers/edac/edac_stub.c | 22 ----------------------
include/linux/edac.h | 2 --
3 files changed, 35 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index f088ea4c66e7..f0c4c890f71b 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -224,17 +224,6 @@ pci_serr_error(unsigned char reason, struct pt_regs *regs)
pr_emerg("NMI: PCI system error (SERR) for reason %02x on CPU %d.\n",
reason, smp_processor_id());
- /*
- * On some machines, PCI SERR line is used to report memory
- * errors. EDAC makes use of it.
- */
-#if defined(CONFIG_EDAC)
- if (edac_handler_set()) {
- edac_atomic_assert_error();
- return;
- }
-#endif
-
if (panic_on_unrecovered_nmi)
nmi_panic(regs, "NMI: Not continuing");
diff --git a/drivers/edac/edac_stub.c b/drivers/edac/edac_stub.c
index 952e411f01f2..d1389e4b7989 100644
--- a/drivers/edac/edac_stub.c
+++ b/drivers/edac/edac_stub.c
@@ -44,25 +44,3 @@ static int __init edac_report_setup(char *str)
return 0;
}
__setup("edac_report=", edac_report_setup);
-
-/*
- * called to determine if there is an EDAC driver interested in
- * knowing an event (such as NMI) occurred
- */
-int edac_handler_set(void)
-{
- if (edac_op_state == EDAC_OPSTATE_POLL)
- return 0;
-
- return atomic_read(&edac_handlers);
-}
-EXPORT_SYMBOL_GPL(edac_handler_set);
-
-/*
- * handler for NMI type of interrupts to assert error
- */
-void edac_atomic_assert_error(void)
-{
- edac_err_assert++;
-}
-EXPORT_SYMBOL_GPL(edac_atomic_assert_error);
diff --git a/include/linux/edac.h b/include/linux/edac.h
index 5b6adf964248..bf8daabf3d51 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -31,8 +31,6 @@ extern int edac_op_state;
extern int edac_err_assert;
extern atomic_t edac_handlers;
-extern int edac_handler_set(void);
-extern void edac_atomic_assert_error(void);
extern struct bus_type *edac_get_sysfs_subsys(void);
enum {
--
2.11.0
next prev parent reply other threads:[~2017-04-06 9:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 9:06 [PATCH 00/11] EDAC: Remove edac_stub.c Borislav Petkov
2017-04-06 9:06 ` [PATCH 01/11] EDAC, highbank: Align Makefile directives Borislav Petkov
2017-04-06 9:06 ` Borislav Petkov [this message]
2017-04-10 13:39 ` [PATCH 02/11] x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI Thomas Gleixner
2017-04-10 14:59 ` Borislav Petkov
2017-04-06 9:06 ` [PATCH 03/11] EDAC: Get rid of edac_handlers Borislav Petkov
2017-04-06 9:06 ` [PATCH 04/11] EDAC: Remove edac_err_assert Borislav Petkov
2017-04-06 9:06 ` [PATCH 05/11] EDAC: Move edac_op_state to edac_mc.c Borislav Petkov
2017-04-06 9:06 ` [PATCH 06/11] ACPI/extlog: Add EDAC dependency Borislav Petkov
2017-04-06 9:06 ` [PATCH 07/11] EDAC: Issue tracepoint only when it is defined Borislav Petkov
2017-04-06 9:06 ` [PATCH 08/11] EDAC: Remove EDAC_MM_EDAC Borislav Petkov
2017-04-06 9:06 ` [PATCH 09/11] EDAC: Update Kconfig help text Borislav Petkov
2017-04-06 9:06 ` [PATCH 10/11] EDAC: Delete edac_stub.c Borislav Petkov
2017-04-06 9:06 ` [PATCH 11/11] EDAC: Rename report status accessors Borislav Petkov
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=20170406090634.30950-3-bp@alien8.de \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox