Dell XPS13: MCE (Hardware Error) reported
Subsystems (8)
Quoted 47 lines · Ashok
Hi Boris
thanks for forwarding.
Quoted 1 line
Quoted 1 line
CPUID Vendor Intel Family 6 Model 142
This is Kabylake Mobile
Quoted 7 lines
Quoted 7 lines
Hardware event. This is not a software error.
MCE 1
CPU 0 BANK 7
MISC 7880018086 ADDRfef1ce40
TIME 1483543069 Wed Jan 4 16:17:49 2017
MCG status:
MCi status:Quoted 8 lines
Quoted 8 lines
Error overflow
Uncorrected errorMCi_MISCregister validMCi_ADDRregister valid
Processor context corrupt
MCA: corrected filtering (some unreported errors in same region) Generic CACHE Level-2 Generic Error
STATUSee0000000040110aMCGSTATUS 0Decoding the bits further from
MCi_STATUSabove:
Val=1, OVER=1, UC=1, but EN=0 indicates this isn't a MCE, hence should have been signaled by a CMCI.PCC=1, but should be ignored when EN=0.
MCACOD: 110a MSCOD: 0040If the system is stable enough after the report, can you send the output of
/proc/interruptsto confirm that.Although its reported as a L2 error, some memory errors can also manifest itself as a cache error in certain cases. In this case it looks like some speculative fetch from bad memory might be the cause.
Quoted 1 line
Quoted 1 line
MCGCAP c08 APICID 0 SOCKETID 0
MCG_CAP: c08
Support CMCI(bit 10) - Corrected Machine Check Interrupt (CMCI_P) and Threshold based error reporting (bit 11) (TES_P).Do you have another machine which doesn't report these errors? if so try swapping memory between them to see if the error disappears.
Quoted 7 lines
I don't have the model specific error handy.. will check that in the meantime to get some decoding as well.
If you haven't already running some memory tests would also help.
If you replaced the motherboard, did that involve both cpu and memory? or just the motheboard swap?
I see the MCE on my XPS 9360 also. It's not related to DRAM, as the physical address is in the non-coherent low MMIO window:
MISC 7880018086 ADDR fef1ce40
Which is declared as device memory:
[ 0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff]
For core-generated cycles, it is between the local APIC space at FEE00000:FEEFFFF and SPI BIOS at FFE00000:FFFFFFFF, so will be subtractively decoded to the PCH, maybe being aborted due to a device not being enabled (hello TPM3 or new image processor).
As it is logged as soon as the MCE driver initialises, it was probably logged during BIOS init, so there's not much we can do about it anyways.
Dan
Signature · 1 line
Daniel J Blueman
Quoted 63 lines · Daniel J Blueman
Quoted 47 lines · Ashok
Hi Boris
thanks for forwarding.
Quoted 1 line
Quoted 1 line
CPUID Vendor Intel Family 6 Model 142
This is Kabylake Mobile
Quoted 7 lines
Quoted 7 lines
Hardware event. This is not a software error.
MCE 1
CPU 0 BANK 7
MISC 7880018086 ADDRfef1ce40
TIME 1483543069 Wed Jan 4 16:17:49 2017
MCG status:
MCi status:Quoted 8 lines
Quoted 8 lines
Error overflow
Uncorrected errorMCi_MISCregister validMCi_ADDRregister valid
Processor context corrupt
MCA: corrected filtering (some unreported errors in same region) Generic CACHE Level-2 Generic Error
STATUSee0000000040110aMCGSTATUS 0Decoding the bits further from
MCi_STATUSabove:
Val=1, OVER=1, UC=1, but EN=0 indicates this isn't a MCE, hence should have been signaled by a CMCI.PCC=1, but should be ignored when EN=0.
MCACOD: 110a MSCOD: 0040If the system is stable enough after the report, can you send the output of
/proc/interruptsto confirm that.Although its reported as a L2 error, some memory errors can also manifest itself as a cache error in certain cases. In this case it looks like some speculative fetch from bad memory might be the cause.
Quoted 1 line
Quoted 1 line
MCGCAP c08 APICID 0 SOCKETID 0
MCG_CAP: c08
Support CMCI(bit 10) - Corrected Machine Check Interrupt (CMCI_P) and Threshold based error reporting (bit 11) (TES_P).Do you have another machine which doesn't report these errors? if so try swapping memory between them to see if the error disappears.
Quoted 7 lines
I don't have the model specific error handy.. will check that in the meantime to get some decoding as well.
If you haven't already running some memory tests would also help.
If you replaced the motherboard, did that involve both cpu and memory? or just the motheboard swap?
I see the MCE on my XPS 9360 also. It's not related to DRAM, as the physical address is in the non-coherent low MMIO window:
MISC 7880018086 ADDRfef1ce40Which is declared as device memory:
[ 0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff]
Quoted 8 lines
For core-generated cycles, it is between the local APIC space at FEE00000:FEEFFFF and SPI BIOS at FFE00000:FFFFFFFF, so will be subtractively decoded to the PCH, maybe being aborted due to a device not being enabled (hello TPM3 or new image processor).
As it is logged as soon as the MCE driver initialises, it was probably logged during BIOS init, so there's not much we can do about it anyways.
That said, I have seen this reoccur after boot; there were no other kernel messages around 300s uptime, and it hasn't occurred in the last hours since:
$ dmesg | grep Machine [ 0.039072] mce: [Hardware Error]: Machine check events logged [ 300.069176] mce: [Hardware Error]: Machine check events logged
As I don't see a driver controlling this area of address space, the access is likely initiated from the UEFI BIOS System Management Mode handler, and we see the same pair of registers FEF1FF40, FEF1CE40 accessed each time.
Dan
Signature · 1 line
Daniel J Blueman
Quoted 5 lines · Daniel J Blueman
That said, I have seen this reoccur after boot; there were no other kernel messages around 300s uptime, and it hasn't occurred in the last hours since:
Not sure if it is related, but I am also seeing those messages on my MacBookPro11,3:
grep -e "Linux version" -e "Machine" oops-2017-01-05-10:32:10-1076-0/dmesg
[ 0.000000] Linux version 4.9.0 (scanf@hafza) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Sun Dec 25 22:25:17 CET 2016 [ 4231.274376] mce: [Hardware Error]: Machine check events logged [ 4231.274893] mce: [Hardware Error]: Machine check events logged [ 4531.292608] mce: [Hardware Error]: Machine check events logged [ 4531.292610] mce: [Hardware Error]: Machine check events logged [ 4833.369927] mce: [Hardware Error]: Machine check events logged [ 4833.370906] mce: [Hardware Error]: Machine check events logged [ 5135.449222] mce: [Hardware Error]: Machine check events logged [ 5135.449228] mce: [Hardware Error]: Machine check events logged [ 5435.564152] mce: [Hardware Error]: Machine check events logged [ 5435.564153] mce: [Hardware Error]: Machine check events logged [ 5735.592854] mce: [Hardware Error]: Machine check events logged [ 5735.592862] mce: [Hardware Error]: Machine check events logged [ 6038.070068] mce: [Hardware Error]: Machine check events logged [ 6038.070073] mce: [Hardware Error]: Machine check events logged [ 6338.170948] mce: [Hardware Error]: Machine check events logged [ 6338.171930] mce: [Hardware Error]: Machine check events logged [ 6920.788280] mce: [Hardware Error]: Machine check events logged [ 6920.788284] mce: [Hardware Error]: Machine check events logged
Signature · 3 lines
Mit freundlichen Grüßen Alexander Alemayhu
Quoted 2 lines · Alexander Alemayhu
Not sure if it is related, but I am also seeing those messages on my MacBookPro11,3:
Yours look to me like thermal throttling MCEs. And TBH we whould not issue those as actual MCEs because they are not - they *signal* overheating condition only and should be handled differently.
What does your /var/log/mcelog* log file contain?
Signature · 5 lines
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- Hi Boris
Quoted 7 lines · Borislav Petkov
Quoted 2 lines · Alexander Alemayhu
Not sure if it is related, but I am also seeing those messages on my MacBookPro11,3:
Yours look to me like thermal throttling MCEs. And TBH we whould not issue those as actual MCEs because they are not - they *signal* overheating condition only and should be handled differently.
That's right.. the thermal interrupts are being reported, that should have started running cpu's at lower frequencies via some thermald. If that's not handled and the PCU starts enforcing trying to keep the temps under control system starts logging MCE's.
Ccing Srinivas who might be able to give a better pointer to check why that's not happening.
The log didn't have the exact MCE's reported.. if you have mcelog, please attach that in the report.
Quoted 9 lines
What does your
/var/log/mcelog*log file contain?Signature · 5 lines
Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Quoted 22 lines · Ashok
Hi Boris
Quoted 10 lines · Borislav Petkov
Quoted 4 lines · Alexander Alemayhu
Not sure if it is related, but I am also seeing those messages on my
MacBookPro11,3:Yours look to me like thermal throttling MCEs. And TBH we whould not issue those as actual MCEs because they are not - they *signal* overheating condition only and should be handled differently.
That's right.. the thermal interrupts are being reported, that should have
started running cpu's at lower frequencies via some thermald. If that's not handled and the PCU starts enforcing trying to keep the temps
under control system starts logging MCE's.
Quoted 3 lines
Ccing Srinivas who might be able to give a better pointer to check why
that's not happening.
I suggest trying with the following kernel command line, if your getting notification to throttle from SMM before:
intel_pstate=support_acpi_ppc
opensuse doesn't start thermald by default.
Thanks,
Srinivas
Quoted 7 lines · Srinivas
I suggest trying with the following kernel command line, if your getting notification to throttle from SMM before:
intel_pstate=support_acpi_ppc
opensuse doesn't start thermald by default.
Used the suggested kernel command line change and made sure thermald[0] is running. I see no more mce* related errors and my fans are making less noise during workloads. Thank you :)
[0]: https://github.com/01org/thermal_daemon
Signature · 3 lines
Mit freundlichen Grüßen Alexander Alemayhu
Quoted 3 lines · Borislav Petkov
What does your
/var/log/mcelog*log file contain?
There are no files there, but in the attached backtrace mcelog is mentioned several times. Sorry I am not familiar with mcelog so I don't know where it would be logging on Fedora.
Signature · 3 lines
Mit freundlichen Grüßen Alexander Alemayhu
The kernel log indicates that hardware errors were detected. System log may have more information.
The last 20 mcelog lines of system log are:
==========================================
Jan 5 10:32:09 hafza mcelog: mcelog: warning: 16 bytes ignored in each record Jan 5 10:32:09 hafza mcelog: mcelog: consider an update Jan 5 10:32:09 hafza mcelog: Hardware event. This is not a software error. Jan 5 10:32:09 hafza mcelog: MCE 0 Jan 5 10:32:09 hafza mcelog: CPU 1 THERMAL EVENT TSC 7722fe2d8c7 Jan 5 10:32:09 hafza mcelog: TIME 1483608727 Thu Jan 5 10:32:07 2017 Jan 5 10:32:09 hafza mcelog: Processor 1 below trip temperature. Throttling disabled Jan 5 10:32:09 hafza mcelog: STATUS 88020a8a MCGSTATUS 0 Jan 5 10:32:09 hafza mcelog: MCGCAP c0a APICID 2 SOCKETID 0 Jan 5 10:32:09 hafza mcelog: CPUID Vendor Intel Family 6 Model 70 Jan 5 10:32:09 hafza mcelog: Hardware event. This is not a software error. Jan 5 10:32:09 hafza mcelog: MCE 1 Jan 5 10:32:09 hafza mcelog: CPU 5 THERMAL EVENT TSC 7722fe316ed Jan 5 10:32:09 hafza mcelog: TIME 1483608727 Thu Jan 5 10:32:07 2017 Jan 5 10:32:09 hafza mcelog: Processor 5 below trip temperature. Throttling disabled Jan 5 10:32:09 hafza mcelog: STATUS 88020a8a MCGSTATUS 0 Jan 5 10:32:09 hafza mcelog: MCGCAP c0a APICID 3 SOCKETID 0 Jan 5 10:32:09 hafza mcelog: CPUID Vendor Intel Family 6 Model 70 Jan 5 10:32:09 hafza mcelog: mcelog: warning: 16 bytes ignored in each record Jan 5 10:32:09 hafza mcelog: mcelog: consider an update
Hi Boris
Quoted 7 lines · Borislav Petkov
Quoted 2 lines · Alexander Alemayhu
Not sure if it is related, but I am also seeing those messages on my MacBookPro11,3:
Yours look to me like thermal throttling MCEs. And TBH we whould not issue those as actual MCEs because they are not - they *signal* overheating condition only and should be handled differently.
After looking at the code, seems like these events are logged as MCE's but are really picked from real lvt thermal event interrupts. via a fake bank 128 for MCE_THERMAL. These are not really HW MCE's, but fake ones created and logged as mcelog entries. (arch/x86/kernel/cpu/mcheck/therm_throt.c)
Quoted 4 lines · Ashok
After looking at the code, seems like these events are logged as MCE's but are really picked from real lvt thermal event interrupts. via a fake bank 128 for
MCE_THERMAL. These are not really HW MCE's, but fake ones created and logged as mcelog entries. (arch/x86/kernel/cpu/mcheck/therm_throt.c)
Right, we've done that since forever but I do think that it confuses people. This thread case-in-point. I mean, we already scream:
pr_crit("CPU%d: %s temperature above threshold, cpu clock throttled (total events = %lu)\n",
to dmesg, why do we have to log a fake MCE too?!
Hell, we even log an MCE when things go back to normal:
if (old_event) {
if (event == THERMAL_THROTTLING_EVENT)
pr_info("CPU%d: %s temperature/speed normal\n", this_cpu,
level == CORE_LEVEL ? "Core" : "Package");
return 1;And Alexander's log shows exactly that:
[ 6338.170924] CPU1: Core temperature above threshold, cpu clock throttled (total events = 21068) [ 6338.170925] CPU5: Core temperature above threshold, cpu clock throttled (total events = 21068) [ 6338.170928] CPU7: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170931] CPU4: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170932] CPU0: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170933] CPU6: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170935] CPU2: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170936] CPU3: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170937] CPU5: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170945] CPU1: Package temperature above threshold, cpu clock throttled (total events = 22842) [ 6338.170947] mce_notify_irq: 1 callbacks suppressed [ 6338.170948] mce: [Hardware Error]: Machine check events logged <--- new event [ 6338.171917] CPU1: Core temperature/speed normal [ 6338.171918] CPU5: Core temperature/speed normal [ 6338.171920] CPU4: Package temperature/speed normal [ 6338.171920] CPU0: Package temperature/speed normal [ 6338.171922] CPU2: Package temperature/speed normal [ 6338.171923] CPU6: Package temperature/speed normal [ 6338.171924] CPU3: Package temperature/speed normal [ 6338.171925] CPU7: Package temperature/speed normal [ 6338.171927] CPU5: Package temperature/speed normal [ 6338.171929] CPU1: Package temperature/speed normal [ 6338.171930] mce: [Hardware Error]: Machine check events logged <--- old event
Oh, and it's not like the user can do anything - there's a thermald which is supposed to deal with all that. Which is not really trouble-free too, TBH. What happens if that thing dies? Fried CPU?
So I say we should rip out that mce_log_therm_throt_event() and never ever handle thermal events with MCEs. It is a bad idea.
Signature · 5 lines
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- Quoted 6 lines · Borislav Petkov
Oh, and it's not like the user can do anything - there's a thermald which is supposed to deal with all that. Which is not really trouble-free too, TBH. What happens if that thing dies? Fried CPU?
So I say we should rip out that
mce_log_therm_throt_event()and never ever handle thermal events with MCEs. It is a bad idea.
Agree, since we have both a log and another agent to deal with it, it makes no good reason to continue... Will pass this along, and have someone look at cleaning this up.
Cheers,
Ashok
Quoted 3 lines · Ashok
Agree, since we have both a log and another agent to deal with it, it makes no good reason to continue... Will pass this along, and have someone look at cleaning this up.
Like this?
---
From: Borislav Petkov <[email protected]>
Date: Fri, 6 Jan 2017 12:07:08 +0100
Subject: [PATCH] x86/MCE/therm_throt: Do not log a fake MCE for a thermal event
We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it should've been done in the first place. And besides we have other means for dealing with thermal events which are much more suitable.
So let's kill the MCE logging part.
--- arch/x86/include/asm/mce.h | 6 ------ arch/x86/kernel/cpu/mcheck/mce.c | 25 ------------------------- arch/x86/kernel/cpu/mcheck/therm_throt.c | 9 ++++----- 3 files changed, 4 insertions(+), 36 deletions(-)
arch/x86/include/asm/mce.h +0 -6
@@ -97,10 +97,6 @@#define MCE_OVERFLOW 0/* bit 0 in flags means overflow */ -/* Software defined banks */ -#define MCE_EXTENDED_BANK 128 -#define MCE_THERMAL_BANK (MCE_EXTENDED_BANK + 0) -#define MCE_LOG_LEN 32#define MCE_LOG_SIGNATURE "MACHINECHECK"
@@ -306,8 +302,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -void mce_log_therm_throt_event (__u64 status); -/* Interrupt Handler for core thermal thresholds */ extern int (*platform_thermal_notify)(__u64 msr_val);
arch/x86/kernel/cpu/mcheck/mce.c +0 -25
@@ -1331,31 +1331,6 @@ static void mce_process_work(struct work_struct *dummy)mce_gen_pool_process (); } -#ifdef CONFIG_X86_MCE_INTEL -/*** -* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog -* @cpu: The CPU on which the event occurred. -* @status: Event status information -* -* This function should be called by the thermal interrupt after the -* event has been processed and the decision was made to log the event -* further. -* -* The status parameter will be saved to the 'status' field of 'struct mce' -* and historically has been the register value of the -* MSR_IA32_THERMAL_STATUS (Intel) msr. -*/ -void mce_log_therm_throt_event (__u64 status) -{ -struct mce m; - -mce_setup (&m); - m.bank =MCE_THERMAL_BANK ; - m.status = status; -mce_log (&m); -} -#endif /* CONFIG_X86_MCE_INTEL */ -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more
arch/x86/kernel/cpu/mcheck/therm_throt.c +4 -5
@@ -6,7 +6,7 @@* * Maintains a counter in /sys that keeps track of the number of thermal * events, such that the user knows how bad the thermal problem might be -* (since the logging to syslog and mcelog is rate limited). +* (since the logging to syslog is rate limited). * * Author: Dmitriy Zavin ([email protected]) *
@@ -365,10 +365,9 @@ static void intel_thermal_interrupt(void)/* Check for violation of core thermal thresholds*/ notify_thresholds (msr_val); -if (therm_throt_process (msr_val &THERM_STATUS_PROCHOT , -THERMAL_THROTTLING_EVENT , -CORE_LEVEL ) !=0 ) -mce_log_therm_throt_event (msr_val); +therm_throt_process (msr_val &THERM_STATUS_PROCHOT , +THERMAL_THROTTLING_EVENT , +CORE_LEVEL );if (this_cpu_has (X86_FEATURE_PLN ) && int_pln_enable) therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
Signature · 4 lines
2.11.0 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Hi Boris
Quoted 6 lines · Borislav Petkov
Quoted 3 lines · Ashok
Agree, since we have both a log and another agent to deal with it, it makes no good reason to continue... Will pass this along, and have someone look at cleaning this up.
Like this?
That was quick :-).
arch/x86/kernel/cpu/mcheck/therm_throt.c static void intel_thermal_interrupt(void) · line 370
Quoted 3 lines
arch/x86/kernel/cpu/mcheck/therm_throt.c +0
-3-if (therm_throt_process (msr_val &THERM_STATUS_PROCHOT , -THERMAL_THROTTLING_EVENT , -CORE_LEVEL ) !=0 )
Looks like we don't need a return value from therm_throt_process(), we can fix that as void as well.
Otherwise it looks good.
arch/x86/kernel/cpu/mcheck/therm_throt.c static void intel_thermal_interrupt(void) · line 370
Quoted 4 lines
arch/x86/kernel/cpu/mcheck/therm_throt.c +3
-0+therm_throt_process (msr_val &THERM_STATUS_PROCHOT , +THERMAL_THROTTLING_EVENT , +CORE_LEVEL );
Cheers,
Ashok
Quoted 2 lines · Ashok
Looks like we don't need a return value from
therm_throt_process(), we can fix that as void as well.
Right you are, here's v2:
---
Quoted 1 line
From
a8151fa6f18c2605eb7972061234f05e79b372c4Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 6 Jan 2017 12:07:08 +0100
Subject: [PATCH] x86/MCE/therm_throt: Do not log a fake MCE for a thermal event
We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it should've been done in the first place. And besides we have other means for dealing with thermal events which are much more suitable.
So let's kill the MCE logging part.
---
v2: Ashok: make therm_throt_process() void.
arch/x86/include/asm/mce.h | 6 ------ arch/x86/kernel/cpu/mcheck/mce.c | 25 ------------------------- arch/x86/kernel/cpu/mcheck/therm_throt.c | 30 +++++++++++------------------- 3 files changed, 11 insertions(+), 50 deletions(-)
arch/x86/include/asm/mce.h +0 -6
@@ -97,10 +97,6 @@#define MCE_OVERFLOW 0/* bit 0 in flags means overflow */ -/* Software defined banks */ -#define MCE_EXTENDED_BANK 128 -#define MCE_THERMAL_BANK (MCE_EXTENDED_BANK + 0) -#define MCE_LOG_LEN 32#define MCE_LOG_SIGNATURE "MACHINECHECK"
@@ -306,8 +302,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -void mce_log_therm_throt_event (__u64 status); -/* Interrupt Handler for core thermal thresholds */ extern int (*platform_thermal_notify)(__u64 msr_val);
arch/x86/kernel/cpu/mcheck/mce.c +0 -25
@@ -1331,31 +1331,6 @@ static void mce_process_work(struct work_struct *dummy)mce_gen_pool_process (); } -#ifdef CONFIG_X86_MCE_INTEL -/*** -* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog -* @cpu: The CPU on which the event occurred. -* @status: Event status information -* -* This function should be called by the thermal interrupt after the -* event has been processed and the decision was made to log the event -* further. -* -* The status parameter will be saved to the 'status' field of 'struct mce' -* and historically has been the register value of the -* MSR_IA32_THERMAL_STATUS (Intel) msr. -*/ -void mce_log_therm_throt_event (__u64 status) -{ -struct mce m; - -mce_setup (&m); - m.bank =MCE_THERMAL_BANK ; - m.status = status; -mce_log (&m); -} -#endif /* CONFIG_X86_MCE_INTEL */ -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more
arch/x86/kernel/cpu/mcheck/therm_throt.c +11 -19
@@ -6,7 +6,7 @@* * Maintains a counter in /sys that keeps track of the number of thermal * events, such that the user knows how bad the thermal problem might be -* (since the logging to syslog and mcelog is rate limited). +* (since the logging to syslog is rate limited). * * Author: Dmitriy Zavin ([email protected]) *
@@ -141,13 +141,8 @@ static struct attribute_group thermal_attr_group = {* IRQ has been acknowledged. * * It will take care of rate limiting and printing messages to the syslog. -* -* Returns: 0 : Event should NOT be further logged, i.e. still in -* "timeout" from previous log message. -* 1 : Event should be logged further, and a message has been -* printed to the syslog. */ -static int therm_throt_process (bool new_event,int event,int level) +static void therm_throt_process (bool new_event,int event,int level) {struct _thermal_state *state;unsigned int this_cpu =smp_processor_id ();
@@ -162,16 +157,16 @@ static int therm_throt_process(bool new_event, int event, int level)else if (event ==POWER_LIMIT_EVENT ) state = &pstate->core_power_limit;else -return 0 ; +return ; }else if (level ==PACKAGE_LEVEL ) {if (event ==THERMAL_THROTTLING_EVENT ) state = &pstate->package_throttle;else if (event ==POWER_LIMIT_EVENT ) state = &pstate->package_power_limit;else -return 0 ; +return ; }else -return 0 ; +return ; old_event = state->new_event; state->new_event = new_event;
@@ -181,7 +176,7 @@ static int therm_throt_process(bool new_event, int event, int level)if (time_before64 (now, state->next_check) && state->count != state->last_count) -return 0 ; +return ; state->next_check = now +CHECK_INTERVAL ; state->last_count = state->count;
@@ -193,16 +188,14 @@ static int therm_throt_process(bool new_event, int event, int level) this_cpu, level ==CORE_LEVEL ?"Core" :"Package" , state->count); -return 1 ; +return ; }if (old_event) {if (event ==THERMAL_THROTTLING_EVENT )pr_info ("CPU%d: %s temperature/speed normal\n" , this_cpu, level ==CORE_LEVEL ?"Core" :"Package" ); -return 1 ; +return ; } - -return 0 ; }static int thresh_event_valid (int level,int event)
@@ -365,10 +358,9 @@ static void intel_thermal_interrupt(void)/* Check for violation of core thermal thresholds*/ notify_thresholds (msr_val); -if (therm_throt_process (msr_val &THERM_STATUS_PROCHOT , -THERMAL_THROTTLING_EVENT , -CORE_LEVEL ) !=0 ) -mce_log_therm_throt_event (msr_val); +therm_throt_process (msr_val &THERM_STATUS_PROCHOT , +THERMAL_THROTTLING_EVENT , +CORE_LEVEL );if (this_cpu_has (X86_FEATURE_PLN ) && int_pln_enable) therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
Signature · 4 lines
2.11.0 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Raj, Ashok
Acked-byHi Boris
This looks good to me!
Quoted 10 lines · Borislav Petkov
Quoted 2 lines · Ashok
Looks like we don't need a return value from
therm_throt_process(), we can fix that as void as well.Right you are, here's v2:
Signed-off-by Borislav Petkov <[email protected]>---
v2: Ashok: make
therm_throt_process()void.
Quoted 5 lines
arch/x86/include/asm/mce.h | 6 ------ arch/x86/kernel/cpu/mcheck/mce.c | 25 ------------------------- arch/x86/kernel/cpu/mcheck/therm_throt.c | 30 +++++++++++------------------- 3 files changed, 11 insertions(+), 50 deletions(-)
Cheers,
Ashok
Quoted 12 lines · Borislav Petkov
Quoted 2 lines · Ashok
Looks like we don't need a return value from
therm_throt_process(), we can fix that as void as well.Right you are, here's v2:
---
Froma8151fa6f18c2605eb7972061234f05e79b372c4Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 6 Jan 2017 12:07:08 +0100
Subject: [PATCH] x86/MCE/therm_throt: Do not log a fake MCE for a thermal event
Quoted 4 lines
We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it should've been done in the first place. And besides
Do you mean *shouldn’t have been done*?
Quoted 6 lines
we have other means for dealing with thermal events which are much more suitable.
So let's kill the MCE logging part.
Signed-off-by Borislav Petkov <[email protected]>
Should the discussion be referenced?
Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks different from what I see, doesn’t it?
[…]
Kind regards,
Paul
Quoted 1 line · Paul Menzel
Do you mean *shouldn’t have been done*?
Yes.
Quoted 1 line
Should the discussion be referenced?
Yap, it will be.
Quoted 2 lines
Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks different from what I see, doesn’t it?
Yes, yours is different. I'm still waiting for you to reply to Ashok's questions here:
https://lkml.kernel.org/r/20170105011236.GA80100@otc-brkl-03
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- Dear Boris,
Quoted 1 line · Borislav Petkov
On Mon, Jan 09, 2017 at 11:55:41AM +0100, Paul Menzel wrote:
[…]
Quoted 7 lines
Quoted 2 lines
Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks different from what I see, doesn’t it?
Yes, yours is different. I'm still waiting for you to reply to Ashok's questions here:
https://lkml.kernel.org/r/20170105011236.GA80100@otc-brkl-03
I see. I thought Daniel’s answered them. I’ll reply now.
Kind regards,
Paul
Borislav Petkov
maintainercover x86/RAS: Queue for 4.11
From: Borislav Petkov <[email protected]>
Hi,
here's the stuff which got ready in time. The more exciting things are going to wait for the next merge window. :-)
Please apply,
thanks.
Borislav Petkov (8):
x86/mce-inject: Make it depend on X86_LOCAL_APIC x86/MCE/therm_throt: Do not log a fake MCE for a thermal event x86/MCE: Flip the TSC-adding logic x86/ras/mce_amd_inj: Change dependency
EDAC/mce_amd: Unexport amd_decode_mce() EDAC/mce_amd: Dump TSC value
x86/MCE: Get rid of mce_process_work()
x86/MCE, EDAC, acpi: Assign MCE notifier handlers a priority
Yazen Ghannam (1):
x86/MCE/AMD: Make sysfs names of banks more user-friendly
arch/x86/Kconfig | 2 +- arch/x86/include/asm/mce.h | 20 ++++++----- arch/x86/kernel/cpu/mcheck/mce-apei.c | 5 ++- arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-inject.c | 5 +-- arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 57 ++++--------------------------- arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 +++-- arch/x86/kernel/cpu/mcheck/therm_throt.c | 30 ++++++---------- arch/x86/ras/Kconfig | 2 +- drivers/acpi/acpi_extlog.c | 1 + drivers/acpi/nfit/mce.c | 1 + drivers/edac/i7core_edac.c | 1 + drivers/edac/mce_amd.c | 8 +++-- drivers/edac/mce_amd.h | 1 - drivers/edac/sb_edac.c | 3 +- drivers/edac/skx_edac.c | 3 +- 17 files changed, 59 insertions(+), 93 deletions(-)
Signature · 1 line
2.11.0
Borislav Petkov
maintainerPATCH 1/9 x86/mce-inject: Make it depend on X86_LOCAL_APIC
From: Borislav Petkov <[email protected]>
... and get rid of the annoying:
arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function]
static void mce_irq_ipi(void *info
when doing randconfig builds.
--- arch/x86/Kconfig | 2 +- arch/x86/kernel/cpu/mcheck/mce-inject.c | 5 +---- 2 files changed, 2 insertions(+), 5 deletions(-)
arch/x86/Kconfig +1 -1
@@ -1070,7 +1070,7 @@ config X86_MCE_THRESHOLD def_bool y config X86_MCE_INJECT - depends on X86_MCE + depends on X86_MCE && X86_LOCAL_APIC tristate "Machine check injector support" ---help--- Provide support for injecting machine checks for testing purposes.
arch/x86/kernel/cpu/mcheck/mce-inject.c +1 -4
@@ -152,7 +152,6 @@ static void raise_mce(struct mce *m)if (context ==MCJ_CTX_RANDOM )return ; -#ifdef CONFIG_X86_LOCAL_APIC if (m->inject_flags & (MCJ_IRQ_BROADCAST |MCJ_NMI_BROADCAST )) {unsigned long start;int cpu;
@@ -192,9 +191,7 @@ static void raise_mce(struct mce *m)raise_local ();put_cpu ();put_online_cpus (); - } else -#endif - { + }else {preempt_disable ();raise_local ();preempt_enable ();
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
Commit-ID: d4b2ac63b0eae461fc10c9791084be24724ef57a Gitweb: http://git.kernel.org/tip/d4b2ac63b0eae461fc10c9791084be24724ef57a Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:06 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:52 +0100
x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
... and get rid of the annoying:
arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function]
when doing randconfig builds.
--- arch/x86/Kconfig | 2 +- arch/x86/kernel/cpu/mcheck/mce-inject.c | 5 +---- 2 files changed, 2 insertions(+), 5 deletions(-)
arch/x86/Kconfig +1 -1
@@ -1070,7 +1070,7 @@ config X86_MCE_THRESHOLD def_bool y config X86_MCE_INJECT - depends on X86_MCE + depends on X86_MCE && X86_LOCAL_APIC tristate "Machine check injector support" ---help--- Provide support for injecting machine checks for testing purposes.
arch/x86/kernel/cpu/mcheck/mce-inject.c +1 -4
@@ -152,7 +152,6 @@ static void raise_mce(struct mce *m)if (context ==MCJ_CTX_RANDOM )return ; -#ifdef CONFIG_X86_LOCAL_APIC if (m->inject_flags & (MCJ_IRQ_BROADCAST |MCJ_NMI_BROADCAST )) {unsigned long start;int cpu;
@@ -192,9 +191,7 @@ static void raise_mce(struct mce *m)raise_local ();put_cpu ();put_online_cpus (); - } else -#endif - { + }else {preempt_disable ();raise_local ();preempt_enable ();
Borislav Petkov
maintainerPATCH 2/9 x86/MCE/therm_throt: Do not log a fake MCE for a thermal event
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it shouldn't have been done in the first place. And besides we have other means for dealing with thermal events which are much more suitable.
So let's kill the MCE logging part.
--- arch/x86/include/asm/mce.h | 6 ------ arch/x86/kernel/cpu/mcheck/mce.c | 25 ------------------------- arch/x86/kernel/cpu/mcheck/therm_throt.c | 30 +++++++++++------------------- 3 files changed, 11 insertions(+), 50 deletions(-)
arch/x86/include/asm/mce.h +0 -6
@@ -97,10 +97,6 @@#define MCE_OVERFLOW 0/* bit 0 in flags means overflow */ -/* Software defined banks */ -#define MCE_EXTENDED_BANK 128 -#define MCE_THERMAL_BANK (MCE_EXTENDED_BANK + 0) -#define MCE_LOG_LEN 32#define MCE_LOG_SIGNATURE "MACHINECHECK"
@@ -306,8 +302,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -void mce_log_therm_throt_event (__u64 status); -/* Interrupt Handler for core thermal thresholds */ extern int (*platform_thermal_notify)(__u64 msr_val);
arch/x86/kernel/cpu/mcheck/mce.c +0 -25
@@ -1331,31 +1331,6 @@ static void mce_process_work(struct work_struct *dummy)mce_gen_pool_process (); } -#ifdef CONFIG_X86_MCE_INTEL -/*** -* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog -* @cpu: The CPU on which the event occurred. -* @status: Event status information -* -* This function should be called by the thermal interrupt after the -* event has been processed and the decision was made to log the event -* further. -* -* The status parameter will be saved to the 'status' field of 'struct mce' -* and historically has been the register value of the -* MSR_IA32_THERMAL_STATUS (Intel) msr. -*/ -void mce_log_therm_throt_event (__u64 status) -{ -struct mce m; - -mce_setup (&m); - m.bank =MCE_THERMAL_BANK ; - m.status = status; -mce_log (&m); -} -#endif /* CONFIG_X86_MCE_INTEL */ -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more
arch/x86/kernel/cpu/mcheck/therm_throt.c +11 -19
@@ -6,7 +6,7 @@* * Maintains a counter in /sys that keeps track of the number of thermal * events, such that the user knows how bad the thermal problem might be -* (since the logging to syslog and mcelog is rate limited). +* (since the logging to syslog is rate limited). * * Author: Dmitriy Zavin ([email protected]) *
@@ -141,13 +141,8 @@ static struct attribute_group thermal_attr_group = {* IRQ has been acknowledged. * * It will take care of rate limiting and printing messages to the syslog. -* -* Returns: 0 : Event should NOT be further logged, i.e. still in -* "timeout" from previous log message. -* 1 : Event should be logged further, and a message has been -* printed to the syslog. */ -static int therm_throt_process (bool new_event,int event,int level) +static void therm_throt_process (bool new_event,int event,int level) {struct _thermal_state *state;unsigned int this_cpu =smp_processor_id ();
@@ -162,16 +157,16 @@ static int therm_throt_process(bool new_event, int event, int level)else if (event ==POWER_LIMIT_EVENT ) state = &pstate->core_power_limit;else -return 0 ; +return ; }else if (level ==PACKAGE_LEVEL ) {if (event ==THERMAL_THROTTLING_EVENT ) state = &pstate->package_throttle;else if (event ==POWER_LIMIT_EVENT ) state = &pstate->package_power_limit;else -return 0 ; +return ; }else -return 0 ; +return ; old_event = state->new_event; state->new_event = new_event;
@@ -181,7 +176,7 @@ static int therm_throt_process(bool new_event, int event, int level)if (time_before64 (now, state->next_check) && state->count != state->last_count) -return 0 ; +return ; state->next_check = now +CHECK_INTERVAL ; state->last_count = state->count;
@@ -193,16 +188,14 @@ static int therm_throt_process(bool new_event, int event, int level) this_cpu, level ==CORE_LEVEL ?"Core" :"Package" , state->count); -return 1 ; +return ; }if (old_event) {if (event ==THERMAL_THROTTLING_EVENT )pr_info ("CPU%d: %s temperature/speed normal\n" , this_cpu, level ==CORE_LEVEL ?"Core" :"Package" ); -return 1 ; +return ; } - -return 0 ; }static int thresh_event_valid (int level,int event)
@@ -365,10 +358,9 @@ static void intel_thermal_interrupt(void)/* Check for violation of core thermal thresholds*/ notify_thresholds (msr_val); -if (therm_throt_process (msr_val &THERM_STATUS_PROCHOT , -THERMAL_THROTTLING_EVENT , -CORE_LEVEL ) !=0 ) -mce_log_therm_throt_event (msr_val); +therm_throt_process (msr_val &THERM_STATUS_PROCHOT , +THERMAL_THROTTLING_EVENT , +CORE_LEVEL );if (this_cpu_has (X86_FEATURE_PLN ) && int_pln_enable) therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras/therm_throt: Do not log a fake MCE for thermal events
x86/ras/therm_throt: Do not log a fake MCE for thermal events
Commit-ID: 9b052ea4ced0fa1ad30a2eafe86984a16297e6f1 Gitweb: http://git.kernel.org/tip/9b052ea4ced0fa1ad30a2eafe86984a16297e6f1 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:07 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:53 +0100
x86/ras/therm_throt: Do not log a fake MCE for thermal events
We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it shouldn't have been done in the first place. And besides we have other means for dealing with thermal events which are much more suitable.
So let's kill the MCE logging part.
--- arch/x86/include/asm/mce.h | 6 ------ arch/x86/kernel/cpu/mcheck/mce.c | 25 ------------------------- arch/x86/kernel/cpu/mcheck/therm_throt.c | 30 +++++++++++------------------- 3 files changed, 11 insertions(+), 50 deletions(-)
arch/x86/include/asm/mce.h +0 -6
@@ -97,10 +97,6 @@#define MCE_OVERFLOW 0/* bit 0 in flags means overflow */ -/* Software defined banks */ -#define MCE_EXTENDED_BANK 128 -#define MCE_THERMAL_BANK (MCE_EXTENDED_BANK + 0) -#define MCE_LOG_LEN 32#define MCE_LOG_SIGNATURE "MACHINECHECK"
@@ -306,8 +302,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -void mce_log_therm_throt_event (__u64 status); -/* Interrupt Handler for core thermal thresholds */ extern int (*platform_thermal_notify)(__u64 msr_val);
arch/x86/kernel/cpu/mcheck/mce.c +0 -25
@@ -1331,31 +1331,6 @@ static void mce_process_work(struct work_struct *dummy)mce_gen_pool_process (); } -#ifdef CONFIG_X86_MCE_INTEL -/*** -* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog -* @cpu: The CPU on which the event occurred. -* @status: Event status information -* -* This function should be called by the thermal interrupt after the -* event has been processed and the decision was made to log the event -* further. -* -* The status parameter will be saved to the 'status' field of 'struct mce' -* and historically has been the register value of the -* MSR_IA32_THERMAL_STATUS (Intel) msr. -*/ -void mce_log_therm_throt_event (__u64 status) -{ -struct mce m; - -mce_setup (&m); - m.bank =MCE_THERMAL_BANK ; - m.status = status; -mce_log (&m); -} -#endif /* CONFIG_X86_MCE_INTEL */ -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more
arch/x86/kernel/cpu/mcheck/therm_throt.c +11 -19
@@ -6,7 +6,7 @@* * Maintains a counter in /sys that keeps track of the number of thermal * events, such that the user knows how bad the thermal problem might be -* (since the logging to syslog and mcelog is rate limited). +* (since the logging to syslog is rate limited). * * Author: Dmitriy Zavin ([email protected]) *
@@ -141,13 +141,8 @@ static struct attribute_group thermal_attr_group = {* IRQ has been acknowledged. * * It will take care of rate limiting and printing messages to the syslog. -* -* Returns: 0 : Event should NOT be further logged, i.e. still in -* "timeout" from previous log message. -* 1 : Event should be logged further, and a message has been -* printed to the syslog. */ -static int therm_throt_process (bool new_event,int event,int level) +static void therm_throt_process (bool new_event,int event,int level) {struct _thermal_state *state;unsigned int this_cpu =smp_processor_id ();
@@ -162,16 +157,16 @@ static int therm_throt_process(bool new_event, int event, int level)else if (event ==POWER_LIMIT_EVENT ) state = &pstate->core_power_limit;else -return 0 ; +return ; }else if (level ==PACKAGE_LEVEL ) {if (event ==THERMAL_THROTTLING_EVENT ) state = &pstate->package_throttle;else if (event ==POWER_LIMIT_EVENT ) state = &pstate->package_power_limit;else -return 0 ; +return ; }else -return 0 ; +return ; old_event = state->new_event; state->new_event = new_event;
@@ -181,7 +176,7 @@ static int therm_throt_process(bool new_event, int event, int level)if (time_before64 (now, state->next_check) && state->count != state->last_count) -return 0 ; +return ; state->next_check = now +CHECK_INTERVAL ; state->last_count = state->count;
@@ -193,16 +188,14 @@ static int therm_throt_process(bool new_event, int event, int level) this_cpu, level ==CORE_LEVEL ?"Core" :"Package" , state->count); -return 1 ; +return ; }if (old_event) {if (event ==THERMAL_THROTTLING_EVENT )pr_info ("CPU%d: %s temperature/speed normal\n" , this_cpu, level ==CORE_LEVEL ?"Core" :"Package" ); -return 1 ; +return ; } - -return 0 ; }static int thresh_event_valid (int level,int event)
@@ -365,10 +358,9 @@ static void intel_thermal_interrupt(void)/* Check for violation of core thermal thresholds*/ notify_thresholds (msr_val); -if (therm_throt_process (msr_val &THERM_STATUS_PROCHOT , -THERMAL_THROTTLING_EVENT , -CORE_LEVEL ) !=0 ) -mce_log_therm_throt_event (msr_val); +therm_throt_process (msr_val &THERM_STATUS_PROCHOT , +THERMAL_THROTTLING_EVENT , +CORE_LEVEL );if (this_cpu_has (X86_FEATURE_PLN ) && int_pln_enable) therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
Borislav Petkov
maintainerPATCH 3/9 x86/MCE/AMD: Make sysfs names of banks more user-friendly
In reply to Borislav PetkovFrom: Yazen Ghannam <[email protected]>
Currently, we append the MCA_IPID[InstanceId] to the bank name to create the sysfs filename. The InstanceId field uniquely identifies a bank instance but it doesn't look very nice for most banks.
Replace the InstanceId with a simpler, ascending (0, 1, ..) value. Only use this in the sysfs name when there is more than 1 instance. Otherwise, just use the bank's name as the sysfs name.
--- arch/x86/include/asm/mce.h | 5 +++-- arch/x86/kernel/cpu/mcheck/mce_amd.c | 6 +++++- 2 files changed, 8 insertions(+), 3 deletions(-)
arch/x86/include/asm/mce.h +3 -2
@@ -356,12 +356,13 @@ struct smca_hwid {unsigned int bank_type;/* Use with smca_bank_types for easy indexing. */ u32 hwid_mcatype;/* (hwid,mcatype) tuple */ u32 xec_bitmap;/* Bitmap of valid ExtErrorCodes; current max is 21. */ +u8 count;/* Number of instances. */ };struct smca_bank {struct smca_hwid *hwid; -/* Instance ID */ -u32 id; +u32 id;/* Value of MCA_IPID[InstanceId]. */ +u8 sysfs_id;/* Value used for sysfs name. */ };extern struct smca_bank smca_banks[MAX_NR_BANKS ];
arch/x86/kernel/cpu/mcheck/mce_amd.c +5 -1
@@ -192,6 +192,7 @@ static void get_smca_bank_info(unsigned int bank) smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = instance_id; + smca_banks[bank].sysfs_id = s_hwid->count++;break ; } }
@@ -1064,9 +1065,12 @@ static const char *get_name(unsigned int bank, struct threshold_block *b)return NULL ; } +if (smca_banks[bank].hwid->count ==1 ) +return smca_get_name (bank_type); +snprintf (buf_mcatype,MAX_MCATYPE_NAME_LEN ,"%s_%x" ,smca_get_name (bank_type), - smca_banks[bank].id); + smca_banks[bank].sysfs_id);return buf_mcatype; }
Signature · 1 line
2.11.0
tip-bot for Yazen Ghannam
merge bot[tip:ras/core] x86/ras/amd: Make sysfs names of banks more user-friendly
x86/ras/amd: Make sysfs names of banks more user-friendly
Commit-ID: 0b737a9c2af85cc8295f9308d9250f9111bbf94d Gitweb: http://git.kernel.org/tip/0b737a9c2af85cc8295f9308d9250f9111bbf94d Author: Yazen Ghannam <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:08 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:53 +0100
x86/ras/amd: Make sysfs names of banks more user-friendly
Currently, we append the MCA_IPID[InstanceId] to the bank name to create the sysfs filename. The InstanceId field uniquely identifies a bank instance but it doesn't look very nice for most banks.
Replace the InstanceId with a simpler, ascending (0, 1, ..) value. Only use this in the sysfs name when there is more than 1 instance. Otherwise, just use the bank's name as the sysfs name.
--- arch/x86/include/asm/mce.h | 5 +++-- arch/x86/kernel/cpu/mcheck/mce_amd.c | 6 +++++- 2 files changed, 8 insertions(+), 3 deletions(-)
arch/x86/include/asm/mce.h +3 -2
@@ -356,12 +356,13 @@ struct smca_hwid {unsigned int bank_type;/* Use with smca_bank_types for easy indexing. */ u32 hwid_mcatype;/* (hwid,mcatype) tuple */ u32 xec_bitmap;/* Bitmap of valid ExtErrorCodes; current max is 21. */ +u8 count;/* Number of instances. */ };struct smca_bank {struct smca_hwid *hwid; -/* Instance ID */ -u32 id; +u32 id;/* Value of MCA_IPID[InstanceId]. */ +u8 sysfs_id;/* Value used for sysfs name. */ };extern struct smca_bank smca_banks[MAX_NR_BANKS ];
arch/x86/kernel/cpu/mcheck/mce_amd.c +5 -1
@@ -192,6 +192,7 @@ static void get_smca_bank_info(unsigned int bank) smca_banks[bank].hwid = s_hwid; smca_banks[bank].id = instance_id; + smca_banks[bank].sysfs_id = s_hwid->count++;break ; } }
@@ -1064,9 +1065,12 @@ static const char *get_name(unsigned int bank, struct threshold_block *b)return NULL ; } +if (smca_banks[bank].hwid->count ==1 ) +return smca_get_name (bank_type); +snprintf (buf_mcatype,MAX_MCATYPE_NAME_LEN ,"%s_%x" ,smca_get_name (bank_type), - smca_banks[bank].id); + smca_banks[bank].sysfs_id);return buf_mcatype; }
Borislav Petkov
maintainerPATCH 4/9 x86/MCE: Flip the TSC-adding logic
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
Add the TSC value to the MCE record only when the MCE being logged is precise, i.e., it is logged as an exception or an MCE-related interrupt.
So it doesn't look particularly easy to do without touching/changing a bunch of places. That's why I'm trying tricks first.
For example, the mce-apei.c case I'm addressing by setting ->tsc only for errors of panic severity. The idea there is, that, panic errors will have raised an #MC and not polled.
And then instead of propagating a flag to mce_setup(), it seems easier/less code to set ->tsc depending on the call sites, i.e., are we polling or are we preparing an MCE record in an exception handler/thresholding interrupt.
--- arch/x86/kernel/cpu/mcheck/mce-apei.c | 5 ++++- arch/x86/kernel/cpu/mcheck/mce.c | 12 +++--------- arch/x86/kernel/cpu/mcheck/mce_amd.c | 3 ++- 3 files changed, 9 insertions(+), 11 deletions(-)
arch/x86/kernel/cpu/mcheck/mce-apei.c +4 -1
@@ -52,8 +52,11 @@ void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err)if (severity >=GHES_SEV_RECOVERABLE ) m.status |=MCI_STATUS_UC ; -if (severity >=GHES_SEV_PANIC ) + +if (severity >=GHES_SEV_PANIC ) { m.status |=MCI_STATUS_PCC ; + m.tsc =rdtsc (); + } m.addr = mem_err->physical_addr;mce_log (&m);
arch/x86/kernel/cpu/mcheck/mce.c +3 -9
@@ -128,7 +128,6 @@ void mce_setup(struct mce *m) {memset (m,0 ,sizeof (struct mce )); m->cpu = m->extcpu =smp_processor_id (); - m->tsc =rdtsc ();/* We hope get_seconds stays lockless */ m->time =get_seconds (); m->cpuvendor = boot_cpu_data.x86_vendor;
@@ -710,14 +709,8 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b)mce_gather_info (&m,NULL ); -/* -* m.tsc was set in mce_setup(). Clear it if not requested. -* -* FIXME: Propagate @flags to mce_gather_info/mce_setup() to avoid -* that dance. -*/ -if (!(flags &MCP_TIMESTAMP )) - m.tsc =0 ; +if (flags &MCP_TIMESTAMP ) + m.tsc =rdtsc ();for (i =0 ; i < mca_cfg.banks; i++) {if (!mce_banks[i].ctl || !test_bit (i, *b))
@@ -1156,6 +1149,7 @@ void do_machine_check(struct pt_regs *regs, long error_code) goto out;mce_gather_info (&m, regs); + m.tsc =rdtsc (); final =this_cpu_ptr (&mces_seen); *final = m;
arch/x86/kernel/cpu/mcheck/mce_amd.c +2 -1
@@ -778,7 +778,8 @@ __log_error(unsigned int bank, bool deferred_err, bool threshold_err, u64 misc)mce_setup (&m); m.status = status; - m.bank = bank; + m.bank = bank; + m.tsc =rdtsc ();if (threshold_err) m.misc = misc;
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras: Flip the TSC-adding logic
x86/ras: Flip the TSC-adding logic
Commit-ID: 669c00f09935fc7a22297eadee04536af141595b Gitweb: http://git.kernel.org/tip/669c00f09935fc7a22297eadee04536af141595b Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:09 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:54 +0100
x86/ras: Flip the TSC-adding logic
Add the TSC value to the MCE record only when the MCE being logged is precise, i.e., it is logged as an exception or an MCE-related interrupt.
So it doesn't look particularly easy to do without touching/changing a bunch of places. That's why I'm trying tricks first.
For example, the mce-apei.c case I'm addressing by setting ->tsc only for errors of panic severity. The idea there is, that, panic errors will have raised an #MC and not polled.
And then instead of propagating a flag to mce_setup(), it seems easier/less code to set ->tsc depending on the call sites, i.e., are we polling or are we preparing an MCE record in an exception handler/thresholding interrupt.
--- arch/x86/kernel/cpu/mcheck/mce-apei.c | 5 ++++- arch/x86/kernel/cpu/mcheck/mce.c | 12 +++--------- arch/x86/kernel/cpu/mcheck/mce_amd.c | 3 ++- 3 files changed, 9 insertions(+), 11 deletions(-)
arch/x86/kernel/cpu/mcheck/mce-apei.c +4 -1
@@ -52,8 +52,11 @@ void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err)if (severity >=GHES_SEV_RECOVERABLE ) m.status |=MCI_STATUS_UC ; -if (severity >=GHES_SEV_PANIC ) + +if (severity >=GHES_SEV_PANIC ) { m.status |=MCI_STATUS_PCC ; + m.tsc =rdtsc (); + } m.addr = mem_err->physical_addr;mce_log (&m);
arch/x86/kernel/cpu/mcheck/mce.c +3 -9
@@ -128,7 +128,6 @@ void mce_setup(struct mce *m) {memset (m,0 ,sizeof (struct mce )); m->cpu = m->extcpu =smp_processor_id (); - m->tsc =rdtsc ();/* We hope get_seconds stays lockless */ m->time =get_seconds (); m->cpuvendor = boot_cpu_data.x86_vendor;
@@ -710,14 +709,8 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b)mce_gather_info (&m,NULL ); -/* -* m.tsc was set in mce_setup(). Clear it if not requested. -* -* FIXME: Propagate @flags to mce_gather_info/mce_setup() to avoid -* that dance. -*/ -if (!(flags &MCP_TIMESTAMP )) - m.tsc =0 ; +if (flags &MCP_TIMESTAMP ) + m.tsc =rdtsc ();for (i =0 ; i < mca_cfg.banks; i++) {if (!mce_banks[i].ctl || !test_bit (i, *b))
@@ -1156,6 +1149,7 @@ void do_machine_check(struct pt_regs *regs, long error_code) goto out;mce_gather_info (&m, regs); + m.tsc =rdtsc (); final =this_cpu_ptr (&mces_seen); *final = m;
arch/x86/kernel/cpu/mcheck/mce_amd.c +2 -1
@@ -778,7 +778,8 @@ __log_error(unsigned int bank, bool deferred_err, bool threshold_err, u64 misc)mce_setup (&m); m.status = status; - m.bank = bank; + m.bank = bank; + m.tsc =rdtsc ();if (threshold_err) m.misc = misc;
Borislav Petkov
maintainerPATCH 5/9 x86/ras/mce_amd_inj: Change dependency
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
Change dependency to mce.c as we're using mce_inject_log() now to stick an MCE into the MCA subsystem.
--- arch/x86/ras/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/ras/Kconfig +1 -1
@@ -1,6 +1,6 @@ config MCE_AMD_INJ tristate "Simple MCE injection interface for AMD processors" - depends on RAS && EDAC_DECODE_MCE && DEBUG_FS && AMD_NB + depends on RAS && X86_MCE && DEBUG_FS && AMD_NB default n help This is a simple debugfs interface to inject MCEs and test different
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras/amd/inj: Change dependency
x86/ras/amd/inj: Change dependency
Commit-ID: bd43f60a260c83cbc9befd7d710a3f2bfd3b2dd2 Gitweb: http://git.kernel.org/tip/bd43f60a260c83cbc9befd7d710a3f2bfd3b2dd2 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:10 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:55 +0100
x86/ras/amd/inj: Change dependency
Change dependency to mce.c as we're using mce_inject_log() now to stick an MCE into the MCA subsystem.
--- arch/x86/ras/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/ras/Kconfig +1 -1
@@ -1,6 +1,6 @@ config MCE_AMD_INJ tristate "Simple MCE injection interface for AMD processors" - depends on RAS && EDAC_DECODE_MCE && DEBUG_FS && AMD_NB + depends on RAS && X86_MCE && DEBUG_FS && AMD_NB default n help This is a simple debugfs interface to inject MCEs and test different
Borislav Petkov
maintainerPATCH 6/9 EDAC/mce_amd: Unexport amd_decode_mce()
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
It is not used outside of the driver anymore.
--- drivers/edac/mce_amd.c | 4 ++-- drivers/edac/mce_amd.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)
drivers/edac/mce_amd.c +2 -2
@@ -942,7 +942,8 @@ static const char *decode_error_status(struct mce *m)return "Corrected error, no action required." ; } -int amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data) +static int +amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data) {struct mce *m = (struct mce *)data;struct cpuinfo_x86 *c = &cpu_data (m->extcpu);
@@ -1047,7 +1048,6 @@ int amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data)return NOTIFY_STOP ; } -EXPORT_SYMBOL_GPL (amd_decode_mce);static struct notifier_block amd_mce_dec_nb = { .notifier_call = amd_decode_mce,
drivers/edac/mce_amd.h +0 -1
@@ -79,6 +79,5 @@ struct amd_decoder_ops {void amd_report_gart_errors (bool );void amd_register_ecc_decoder (void (*f)(int ,struct mce *));void amd_unregister_ecc_decoder (void (*f)(int ,struct mce *)); -int amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data);#endif /* _EDAC_MCE_AMD_H */
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] EDAC/mce/amd: Unexport amd_decode_mce()
EDAC/mce/amd: Unexport amd_decode_mce()
Commit-ID: 1fbcd909035251b5eac267f1c5d6d67b32d16b62 Gitweb: http://git.kernel.org/tip/1fbcd909035251b5eac267f1c5d6d67b32d16b62 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:11 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:55 +0100
EDAC/mce/amd: Unexport amd_decode_mce()
It is not used outside of the driver anymore.
--- drivers/edac/mce_amd.c | 4 ++-- drivers/edac/mce_amd.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)
drivers/edac/mce_amd.c +2 -2
@@ -942,7 +942,8 @@ static const char *decode_error_status(struct mce *m)return "Corrected error, no action required." ; } -int amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data) +static int +amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data) {struct mce *m = (struct mce *)data;struct cpuinfo_x86 *c = &cpu_data (m->extcpu);
@@ -1047,7 +1048,6 @@ int amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data)return NOTIFY_STOP ; } -EXPORT_SYMBOL_GPL (amd_decode_mce);static struct notifier_block amd_mce_dec_nb = { .notifier_call = amd_decode_mce,
drivers/edac/mce_amd.h +0 -1
@@ -79,6 +79,5 @@ struct amd_decoder_ops {void amd_report_gart_errors (bool );void amd_register_ecc_decoder (void (*f)(int ,struct mce *));void amd_unregister_ecc_decoder (void (*f)(int ,struct mce *)); -int amd_decode_mce (struct notifier_block *nb,unsigned long val,void *data);#endif /* _EDAC_MCE_AMD_H */
Borislav Petkov
maintainerPATCH 7/9 EDAC/mce_amd: Dump TSC value
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
Dump the TSC value of the time when the MCE got logged.
--- drivers/edac/mce_amd.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/edac/mce_amd.c +3 -0
@@ -1007,6 +1007,9 @@ amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data) }else pr_cont ("\n" ); +if (m->tsc) +pr_emerg (HW_ERR "TSC: %llu\n" , m->tsc); +if (!fam_ops) goto err_code;
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] EDAC/mce/amd: Dump TSC value
EDAC/mce/amd: Dump TSC value
Commit-ID: 0bceab677dcef409f6281d922461057721d547b3 Gitweb: http://git.kernel.org/tip/0bceab677dcef409f6281d922461057721d547b3 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:12 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:56 +0100
EDAC/mce/amd: Dump TSC value
Dump the TSC value of the time when the MCE got logged.
--- drivers/edac/mce_amd.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/edac/mce_amd.c +3 -0
@@ -1007,6 +1007,9 @@ amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data) }else pr_cont ("\n" ); +if (m->tsc) +pr_emerg (HW_ERR "TSC: %llu\n" , m->tsc); +if (!fam_ops) goto err_code;
Borislav Petkov
maintainerPATCH 8/9 x86/MCE: Get rid of mce_process_work()
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
Make mce_gen_pool_process() the workqueue function directly and save us an indirection.
--- arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 12 +----------- 3 files changed, 3 insertions(+), 13 deletions(-)
arch/x86/kernel/cpu/mcheck/mce-genpool.c +1 -1
@@ -72,7 +72,7 @@ struct llist_node *mce_gen_pool_prepare_records(void)return new_head.first; } -void mce_gen_pool_process (void ) +void mce_gen_pool_process (struct work_struct *__unused) {struct llist_node *head;struct mce_evt_llist *node, *tmp;
arch/x86/kernel/cpu/mcheck/mce-internal.h +1 -1
@@ -31,7 +31,7 @@ struct mce_evt_llist {struct mce mce; }; -void mce_gen_pool_process (void ); +void mce_gen_pool_process (struct work_struct *__unused);bool mce_gen_pool_empty (void );int mce_gen_pool_add (struct mce *mce);int mce_gen_pool_init (void );
arch/x86/kernel/cpu/mcheck/mce.c +1 -11
@@ -1316,16 +1316,6 @@ int memory_failure(unsigned long pfn, int vector, int flags)#endif /* -* Action optional processing happens here (picking up -* from the list of faulting pages that do_machine_check() -* placed into the genpool). -*/ -static void mce_process_work (struct work_struct *dummy) -{ -mce_gen_pool_process (); -} - -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more * errors, poll 2x slower (up to check_interval seconds).
@@ -2165,7 +2155,7 @@ int __init mcheck_init(void)mce_register_decode_chain (&mce_default_nb);mcheck_vendor_init_severity (); -INIT_WORK (&mce_work, mce_process_work); +INIT_WORK (&mce_work, mce_gen_pool_process);init_irq_work (&mce_irq_work, mce_irq_work_cb);return 0 ;
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras: Get rid of mce_process_work()
x86/ras: Get rid of mce_process_work()
Commit-ID: cff4c0391a692cf9b89932c62a7f879fb3637148 Gitweb: http://git.kernel.org/tip/cff4c0391a692cf9b89932c62a7f879fb3637148 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:13 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:56 +0100
x86/ras: Get rid of mce_process_work()
Make mce_gen_pool_process() the workqueue function directly and save us an indirection.
--- arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 12 +----------- 3 files changed, 3 insertions(+), 13 deletions(-)
arch/x86/kernel/cpu/mcheck/mce-genpool.c +1 -1
@@ -72,7 +72,7 @@ struct llist_node *mce_gen_pool_prepare_records(void)return new_head.first; } -void mce_gen_pool_process (void ) +void mce_gen_pool_process (struct work_struct *__unused) {struct llist_node *head;struct mce_evt_llist *node, *tmp;
arch/x86/kernel/cpu/mcheck/mce-internal.h +1 -1
@@ -31,7 +31,7 @@ struct mce_evt_llist {struct mce mce; }; -void mce_gen_pool_process (void ); +void mce_gen_pool_process (struct work_struct *__unused);bool mce_gen_pool_empty (void );int mce_gen_pool_add (struct mce *mce);int mce_gen_pool_init (void );
arch/x86/kernel/cpu/mcheck/mce.c +1 -11
@@ -1316,16 +1316,6 @@ int memory_failure(unsigned long pfn, int vector, int flags)#endif /* -* Action optional processing happens here (picking up -* from the list of faulting pages that do_machine_check() -* placed into the genpool). -*/ -static void mce_process_work (struct work_struct *dummy) -{ -mce_gen_pool_process (); -} - -/* * Periodic polling timer for "silent" machine check errors. If the * poller finds an MCE, poll 2x faster. When the poller finds no more * errors, poll 2x slower (up to check_interval seconds).
@@ -2165,7 +2155,7 @@ int __init mcheck_init(void)mce_register_decode_chain (&mce_default_nb);mcheck_vendor_init_severity (); -INIT_WORK (&mce_work, mce_process_work); +INIT_WORK (&mce_work, mce_gen_pool_process);init_irq_work (&mce_irq_work, mce_irq_work_cb);return 0 ;
Borislav Petkov
maintainerPATCH 9/9 x86/MCE, EDAC, acpi: Assign MCE notifier handlers a priority
In reply to Borislav PetkovFrom: Borislav Petkov <[email protected]>
Assign all notifiers on the MCE decode chain a priority so that they get called in the correct order.
--- arch/x86/include/asm/mce.h | 9 +++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 8 +++----- drivers/acpi/acpi_extlog.c | 1 + drivers/acpi/nfit/mce.c | 1 + drivers/edac/i7core_edac.c | 1 + drivers/edac/mce_amd.c | 1 + drivers/edac/sb_edac.c | 3 ++- drivers/edac/skx_edac.c | 3 ++- 8 files changed, 20 insertions(+), 7 deletions(-)
arch/x86/include/asm/mce.h +9 -0
@@ -189,6 +189,15 @@ extern struct mce_vendor_flags mce_flags;extern struct mca_config mca_cfg;extern struct mca_msr_regs msr_ops; + +enum mce_notifier_prios { +MCE_PRIO_SRAO =INT_MAX , +MCE_PRIO_EXTLOG =INT_MAX -1 , +MCE_PRIO_NFIT =INT_MAX -2 , +MCE_PRIO_EDAC =INT_MAX -3 , +MCE_PRIO_LOWEST =0 , +}; +extern void mce_register_decode_chain (struct notifier_block *nb);extern void mce_unregister_decode_chain (struct notifier_block *nb);
arch/x86/kernel/cpu/mcheck/mce.c +3 -5
@@ -216,9 +216,7 @@ void mce_register_decode_chain(struct notifier_block *nb) {atomic_inc (&num_notifiers); -/* Ensure SRAO notifier has the highest priority in the decode chain. */ -if (nb != &mce_srao_nb && nb->priority ==INT_MAX ) - nb->priority -=1 ; +WARN_ON (nb->priority >MCE_PRIO_LOWEST && nb->priority <MCE_PRIO_EDAC );atomic_notifier_chain_register (&x86_mce_decoder_chain, nb); }
@@ -582,7 +580,7 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val, }static struct notifier_block mce_srao_nb = { .notifier_call = srao_decode_notifier, - .priority =INT_MAX , + .priority =MCE_PRIO_SRAO , }; static int mce_default_notifier(struct notifier_block *nb, unsigned long val,
@@ -608,7 +606,7 @@ static int mce_default_notifier(struct notifier_block *nb, unsigned long val,static struct notifier_block mce_default_nb = { .notifier_call = mce_default_notifier,/* lowest prio, we want it to run last. */ - .priority =0 , + .priority =MCE_PRIO_LOWEST , };/*
drivers/acpi/acpi_extlog.c +1 -0
@@ -212,6 +212,7 @@ static bool __init extlog_get_l1addr(void) }static struct notifier_block extlog_mce_dec = { .notifier_call = extlog_print, + .priority =MCE_PRIO_EXTLOG , };static int __init extlog_init (void )
drivers/acpi/nfit/mce.c +1 -0
@@ -90,6 +90,7 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,static struct notifier_block nfit_mce_dec = { .notifier_call = nfit_handle_mce, + .priority =MCE_PRIO_NFIT , };void nfit_mce_register (void )
drivers/edac/i7core_edac.c +1 -0
@@ -1835,6 +1835,7 @@ static int i7core_mce_check_error(struct notifier_block *nb, unsigned long val,static struct notifier_block i7_mce_dec = { .notifier_call = i7core_mce_check_error, + .priority =MCE_PRIO_EDAC , };struct memdev_dmi_entry {
drivers/edac/mce_amd.c +1 -0
@@ -1054,6 +1054,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data)static struct notifier_block amd_mce_dec_nb = { .notifier_call = amd_decode_mce, + .priority =MCE_PRIO_EDAC , };static int __init mce_amd_init (void )
drivers/edac/sb_edac.c +2 -1
@@ -3136,7 +3136,8 @@ static int sbridge_mce_check_error(struct notifier_block *nb, unsigned long val, }static struct notifier_block sbridge_mce_dec = { - .notifier_call = sbridge_mce_check_error, + .notifier_call = sbridge_mce_check_error, + .priority =MCE_PRIO_EDAC , };/****************************************************************************
drivers/edac/skx_edac.c +2 -1
@@ -1007,7 +1007,8 @@ static int skx_mce_check_error(struct notifier_block *nb, unsigned long val, }static struct notifier_block skx_mce_dec = { - .notifier_call = skx_mce_check_error, + .notifier_call = skx_mce_check_error, + .priority =MCE_PRIO_EDAC , };static void skx_remove (void )
Signature · 1 line
2.11.0
tip-bot for Borislav Petkov
merge bot[tip:ras/core] x86/ras, EDAC, acpi: Assign MCE notifier handlers a priority
x86/ras, EDAC, acpi: Assign MCE notifier handlers a priority
Commit-ID: 9026cc82b632ed1a859935c82ed8ad65f27f2781 Gitweb: http://git.kernel.org/tip/9026cc82b632ed1a859935c82ed8ad65f27f2781 Author: Borislav Petkov <[email protected]> AuthorDate: Mon, 23 Jan 2017 19:35:14 +0100 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 24 Jan 2017 09:14:57 +0100
x86/ras, EDAC, acpi: Assign MCE notifier handlers a priority
Assign all notifiers on the MCE decode chain a priority so that they get called in the correct order.
--- arch/x86/include/asm/mce.h | 9 +++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 8 +++----- drivers/acpi/acpi_extlog.c | 1 + drivers/acpi/nfit/mce.c | 1 + drivers/edac/i7core_edac.c | 1 + drivers/edac/mce_amd.c | 1 + drivers/edac/sb_edac.c | 3 ++- drivers/edac/skx_edac.c | 3 ++- 8 files changed, 20 insertions(+), 7 deletions(-)
arch/x86/include/asm/mce.h +9 -0
@@ -189,6 +189,15 @@ extern struct mce_vendor_flags mce_flags;extern struct mca_config mca_cfg;extern struct mca_msr_regs msr_ops; + +enum mce_notifier_prios { +MCE_PRIO_SRAO =INT_MAX , +MCE_PRIO_EXTLOG =INT_MAX -1 , +MCE_PRIO_NFIT =INT_MAX -2 , +MCE_PRIO_EDAC =INT_MAX -3 , +MCE_PRIO_LOWEST =0 , +}; +extern void mce_register_decode_chain (struct notifier_block *nb);extern void mce_unregister_decode_chain (struct notifier_block *nb);
arch/x86/kernel/cpu/mcheck/mce.c +3 -5
@@ -216,9 +216,7 @@ void mce_register_decode_chain(struct notifier_block *nb) {atomic_inc (&num_notifiers); -/* Ensure SRAO notifier has the highest priority in the decode chain. */ -if (nb != &mce_srao_nb && nb->priority ==INT_MAX ) - nb->priority -=1 ; +WARN_ON (nb->priority >MCE_PRIO_LOWEST && nb->priority <MCE_PRIO_EDAC );atomic_notifier_chain_register (&x86_mce_decoder_chain, nb); }
@@ -582,7 +580,7 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val, }static struct notifier_block mce_srao_nb = { .notifier_call = srao_decode_notifier, - .priority =INT_MAX , + .priority =MCE_PRIO_SRAO , }; static int mce_default_notifier(struct notifier_block *nb, unsigned long val,
@@ -608,7 +606,7 @@ static int mce_default_notifier(struct notifier_block *nb, unsigned long val,static struct notifier_block mce_default_nb = { .notifier_call = mce_default_notifier,/* lowest prio, we want it to run last. */ - .priority =0 , + .priority =MCE_PRIO_LOWEST , };/*
drivers/acpi/acpi_extlog.c +1 -0
@@ -212,6 +212,7 @@ static bool __init extlog_get_l1addr(void) }static struct notifier_block extlog_mce_dec = { .notifier_call = extlog_print, + .priority =MCE_PRIO_EXTLOG , };static int __init extlog_init (void )
drivers/acpi/nfit/mce.c +1 -0
@@ -90,6 +90,7 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,static struct notifier_block nfit_mce_dec = { .notifier_call = nfit_handle_mce, + .priority =MCE_PRIO_NFIT , };void nfit_mce_register (void )
drivers/edac/i7core_edac.c +1 -0
@@ -1835,6 +1835,7 @@ static int i7core_mce_check_error(struct notifier_block *nb, unsigned long val,static struct notifier_block i7_mce_dec = { .notifier_call = i7core_mce_check_error, + .priority =MCE_PRIO_EDAC , };struct memdev_dmi_entry {
drivers/edac/mce_amd.c +1 -0
@@ -1054,6 +1054,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data)static struct notifier_block amd_mce_dec_nb = { .notifier_call = amd_decode_mce, + .priority =MCE_PRIO_EDAC , };static int __init mce_amd_init (void )
drivers/edac/sb_edac.c +2 -1
@@ -3136,7 +3136,8 @@ static int sbridge_mce_check_error(struct notifier_block *nb, unsigned long val, }static struct notifier_block sbridge_mce_dec = { - .notifier_call = sbridge_mce_check_error, + .notifier_call = sbridge_mce_check_error, + .priority =MCE_PRIO_EDAC , };/****************************************************************************
drivers/edac/skx_edac.c +2 -1
@@ -1007,7 +1007,8 @@ static int skx_mce_check_error(struct notifier_block *nb, unsigned long val, }static struct notifier_block skx_mce_dec = { - .notifier_call = skx_mce_check_error, + .notifier_call = skx_mce_check_error, + .priority =MCE_PRIO_EDAC , };static void skx_remove (void )