- 04 Dec, 2016 1 commit
-
-
Pan Bian authored
When the call to zalloc_cpumask_var() fails, returning "false" seems improper. The real value of macro "false" is 0, and 0 means no error. Return -ENOMEM instead. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189071Signed-off-by:
Pan Bian <bianpan2016@163.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1480831638-5361-1-git-send-email-bianpan201604@163.comSigned-off-by:
Borislav Petkov <bp@suse.de>
-
- 01 Dec, 2016 1 commit
-
-
Borislav Petkov authored
Prefix the warn and error macros with the respective string so that callers don't have to say "Error" or "Warning". We save us string length this way in the actual calls. While at it, shorten the calls in reserve_mc_sibling_devs(). Signed-off-by:
-
- 29 Nov, 2016 5 commits
-
-
Yazen Ghannam authored
Add Fam17h to the list of families to autoload amd64_edac_mod. Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> Cc: Aravind Gopalakrishnan <aravindksg.lkml@gmail.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/1479423463-8536-18-git-send-email-Yazen.Ghannam@amd.comSigned-off-by:
-
Yazen Ghannam authored
How we need to decode UMC errors is different from how we decode bus errors, so let's define a new function for this. We also need a way to determine the UMC channel since we're not guaranteed that there is a fixed relation between channel and MCA bank. Signed-off-by:
-
Yazen Ghannam authored
We need to determine the EDAC capabilities from all UMCs on the node. We should only check UMCs that are enabled and make sure they all agree. Signed-off-by:
-
Yazen Ghannam authored
The UMCs on Fam17h are independent memory controllers so we need to read the capabilities from all UMCs and make sure they agree. Once we determine what capabilities are available we should save them for convenience. Signed-off-by:
-
Yazen Ghannam authored
Read a few more UMC registers and provide debug output in order to be as similar as possible to older AMD systems. Signed-off-by:
-
- 28 Nov, 2016 4 commits
-
-
Yazen Ghannam authored
Fam17h has new register offsets and fields for setting up the DRAM scrubber so add support for this. Signed-off-by:
-
Yazen Ghannam authored
MCA_STATUS[43] has been defined as "Poison" or "Reserved" for every bank since Fam15h except for Fam15h, bank 4 in which case it's defined as part of the McaStatSubCache bitfield. Filter out that case. Reported-by:
Dean Liberty <Dean.Liberty@amd.com> Signed-off-by:
-
Yazen Ghannam authored
Fam17h has a different set of registers and bitfields. Most of these registers are read through SMN (System Management Network) rather than PCI config space. Also, the derivation of various values is now different. Update amd64_edac to read the appropriate registers and extract the correct values for Fam17h. Signed-off-by:
-
Yazen Ghannam authored
Fam17h needs PCI device functions 0 and 6 instead of 1 and 2 as on older systems. Update struct amd64_pvt to hold the new functions and reserve them if on Fam17h. Also, allocate an array of UMC structs within our newly allocated PVT struct. Signed-off-by:
-
- 24 Nov, 2016 2 commits
-
-
Yazen Ghannam authored
Add a family type and associated ops for Fam17h. Define a struct to hold all the UMC registers that we need. Make this a part of struct amd64_pvt in order to maximize code reuse in the rest of the driver. Signed-off-by:
-
Yazen Ghannam authored
Update the ecc_enabled() function to work on Fam17h. This entails reading a different set of registers and using the SMN (System Management Network) rather than PCI devices. Signed-off-by:
-
- 23 Nov, 2016 3 commits
-
-
Borislav Petkov authored
tip:ras/core contains the respective Fam17h x86 RAS bits which amd64_edac is going to use. So merge it into the EDAC branch. Signed-off-by: -
Yazen Ghannam authored
It's not recommended for the OS to try and force-enable ECC checking. This is considered a firmware task since it includes memory training, etc, so don't change ECC settings on Fam17h or newer systems and inform the user. Signed-off-by:
-
Tony Luck authored
Intel Xeons from Ivy Bridge onwards support a processor identification number set in the factory. To the user this is a handy unique number to identify a particular CPU. Intel can decode this to the fab/production run to track errors. On systems that have it, include it in the machine check record. I'm told that this would be helpful for users that run large data centers with multi-socket servers to keep track of which CPUs are seeing errors. Boris: * Add some clarifying comments and spacing. * Mask out [63:2] in the disabled-but-not-locked case * Call the MSR variable "val" for more readability. Signed-off-by:
Tony Luck <tony.luck@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20161123114855.njguoaygp3qnbkia@pd.tnicSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 22 Nov, 2016 1 commit
-
-
Yazen Ghannam authored
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address in their MCA_ADDR registers. We need to convert that normalized address to a system physical address in order to support a few facilities: 1) To offline poisoned pages in DRAM proactively in the deferred error handler. 2) To print sysaddr and page info for DRAM ECC errors in EDAC. [ Boris: fixes/cleanups ontop: * hi_addr_offset = 0 - no need for that branch. Stick it all under the HiAddrOffsetEn case. It confines hi_addr_offset's declaration too. * Move variables to the innermost scope they're used at so that we save on stack and not blow it up immediately on function entry. * Do not modify *sys_addr prematurely - we want to not exit early and have modified *sys_addr some, which callers get to see. We either convert to a sys_addr or we don't do anything. And we signal that with the retval of the function. * Rename label out -> out_err - because it is the error path. * No need to pr_err of the conversion failed case: imagine a sparsely-populated machine with UMCs which don't have DIMMs. Callers should look at the retval instead and issue a printk only when really necessary. No need for useless info in dmesg. * s/temp_reg/tmp/ and other variable names shortening => shorter code. * Use BIT() everywhere. * Make error messages more informative. * Small build fix for the !CONFIG_X86_MCE_AMD case. * ... and more minor cleanups. ] Signed-off-by:Ingo Molnar <mingo@kernel.org>
-
- 21 Nov, 2016 5 commits
-
-
Yazen Ghannam authored
Currently, deferred errors are classified as correctable in EDAC. Add a new error type for deferred errors so that they are correctly reported to the user. Signed-off-by:
-
Yazen Ghannam authored
We only use __log_bus_error() to log DRAM ECC errors, so let's change the name to reflect this. We'll also use this function for DRAM ECC errors on Fam17h, but we'll call it from a different function than decode_bus_error(). Signed-off-by:
-
Yazen Ghannam authored
AMD Fam17h will not be using PCI function 2 for EDAC, but will continue to use function 3. So let's get the name of F3 instead of F2 to support Fam17h and previous families. Signed-off-by:
-
Yazen Ghannam authored
nb_bus_decoder() is only used for DRAM ECC errors so rename it so that the name is more generic and descriptive. Also, call it for DRAM ECC errors on SMCA systems. [ Boris: rename it to real function name with a verb in it. ] Signed-off-by:
-
Yazen Ghannam authored
AMD Fam17h systems can support Load-Reduced DDR4 DIMMs. So add this new type to edac.h in preparation for the Fam17h EDAC update. Also, let's fix a format issue with the LRDDR3 line while we're here. Signed-off-by:
-
- 17 Nov, 2016 1 commit
-
-
Yanjiang Jin authored
If we execute the below steps without this patch: modprobe mpc85xx_edac [The first insmod, everything is well.] modprobe -r mpc85xx_edac modprobe mpc85xx_edac [insmod again, error happens.] We would get the error messages as below: BUG: recent printk recursion! Oops: Kernel access of bad area, sig: 11 [#48] Modules linked in: mpc85xx_edac edac_core softdog [last unloaded: mpc85xx_edac] CPU: 5 PID: 14773 Comm: modprobe Tainted: G D C 4.8.3-rt2 .vsnprintf .vscnprintf .vprintk_emit .printk .edac_pci_add_device .mpc85xx_pci_err_probe .platform_drv_probe .driver_probe_device .__driver_attach .bus_for_each_dev .driver_attach .bus_add_driver .driver_register .__platform_register_drivers .mpc85xx_mc_init .do_one_initcall .do_init_module .load_module .SyS_finit_module system_call Address this by cleaning up properly when removing the platform driver. Tested on a T4240QDS board. Signed-off-by:
Yanjiang Jin <yanjiang.jin@windriver.com> Acked-by:
Johannes Thumshirn <jthumshirn@suse.de> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: york.sun@nxp.com Link: http://lkml.kernel.org/r/1479351380-17109-2-git-send-email-yanjiang.jin@windriver.com [ Boris: massage commit message. ] Signed-off-by:
-
- 16 Nov, 2016 5 commits
-
-
Yazen Ghannam authored
Some devices on Fam17h can only be accessed through the System Management Network (SMN). The SMN is accessed by a pair of index/data registers in PCI config space. Add a pair of functions to read from and write to the SMN. The Data Fabric on Fam17h allows multiple devices to use the same register space. The registers of a specific device are accessed indirectly using the device's DF InstanceId. Currently, we only need to read from these devices, so only define a read function for now. Signed-off-by:
-
Yazen Ghannam authored
AMD Fam17h uses a Data Fabric component instead of a traditional Northbridge. However, the DF is similar to a NB in that there is one per die and it uses PCI config D18Fx registers. So let's reuse the existing AMD_NB infrastructure for Data Fabrics. Signed-off-by:
-
Yazen Ghannam authored
Make all EXPORT_SYMBOL's into EXPORT_SYMBOL_GPL. While we're at it let's fix some checkpatch warnings. Signed-off-by:
-
Yazen Ghannam authored
Hide amd_northbridges in amd_nb.c so that external callers will have to use the exported accessor functions. Also, fix some checkpatch.pl warnings. Signed-off-by:
-
Yazen Ghannam authored
The error count field in MCA_MISC does not get reset by hardware when the threshold has been reached. Software is expected to reset it. Currently, the threshold limit only gets reset during init or when a user writes to sysfs. If the user is not monitoring threshold interrupts and resetting the limit then the user will only see 1 interrupt when the limit is first hit. So if, for example, the limit is set to 10 then only 1 interrupt will be recorded after 10 errors even if 100 errors have occurred. The user may then assume that only 10 errors have occurred. Signed-off-by:
-
- 15 Nov, 2016 1 commit
-
-
Colin Ian King authored
Trivial fix to spelling mistake "Mutilple" to "Multiple" in error messages. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Loc Ho <lho@apm.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20161114231104.5585-1-colin.king@canonical.comSigned-off-by:
-
- 14 Nov, 2016 1 commit
-
-
Borislav Petkov authored
When accessing the mc_devices list of memory controller descriptors, we need to hold mem_ctls_mutex. This was not always the case, fix that. Make all external callers call a version which grabs the mutex since the last is local to edac_mc.c. Reported-by:
-
- 11 Nov, 2016 2 commits
-
-
Yazen Ghannam authored
The calculation of the hwid_mcatype value in get_smca_bank_info() became incorrect after applying the following commit: 1ce9cd7f ("x86/RAS: Simplify SMCA HWID descriptor struct") This causes the function to not match a bank to its type. Disassembly of hwid_mcatype calculation after change: db: 8b 45 e0 mov -0x20(%rbp),%eax de: 41 89 c4 mov %eax,%r12d e1: 25 00 00 ff 0f and $0xfff0000,%eax e6: 41 c1 ec 10 shr $0x10,%r12d ea: 41 09 c4 or %eax,%r12d Disassembly of hwid_mcatype calculation in original code: 286: 8b 45 d0 mov -0x30(%rbp),%eax 289: 41 89 c5 mov %eax,%r13d 28c: c1 e8 10 shr $0x10,%eax 28f: 41 81 e5 ff 0f 00 00 and $0xfff,%r13d 296: 41 c1 e5 10 shl $0x10,%r13d 29a: 41 09 c5 or %eax,%r13d Grouping the arguments to the HWID_MCATYPE() macro fixes the issue. ( Boris suggested adding parentheses in the macro. ) Signed-off-by:
-
Borislav Petkov authored
We did have logic in the MCE code which would TSC-timestamp an error record only when it is exact - i.e., when it wasn't detected by polling. This isn't the case anymore. So let's fix that: We have a valid TSC timestamp in the error record only when it has been a precise detection, i.e., either in the #MC handler or in one of the interrupt handlers (thresholding, deferred, ...). All other error records still have mce.time which contains the wall time in order to be able to place the error record in time at least approximately. Also, this fixes another bug where machine_check_poll() would clear mce.tsc unconditionally even if we requested precise MCP_TIMESTAMP logging. The proper fix would be to generate timestamp only when it has been requested and not always. But that would require a more thorough code audit of all mce_gather_info/mce_setup() users. Add a FIXME for now. Signed-off-by:
-
- 08 Nov, 2016 7 commits
-
-
Borislav Petkov authored
Add accessor functions and hide the smca_names array. Also, add a sanity-check to bank HWID assignment in get_smca_bank_info(). Signed-off-by:
-
Borislav Petkov authored
Make it differ more from struct smca_bank_name for better readability. Signed-off-by:
-
Borislav Petkov authored
Call it simply smca_hwid and call local variables "hwid". More readable. Signed-off-by:
-
Borislav Petkov authored
Call the struct simply smca_bank, it's instance ID can be simply ->id. Makes the code much more readable. Signed-off-by:
-
Borislav Petkov authored
When there are no error record consumers registered with the kernel, the only thing that appears in dmesg is something like: [ 300.000326] mce: [Hardware Error]: Machine check events logged and the error records are gone. Which is seriously counterproductive. So let's dump them to dmesg instead, in such a case. Requested-by:
Eric Morton <Eric.Morton@amd.com> Signed-off-by:
-
Borislav Petkov authored
The MCE injection code does not provide the time stamp information for the injected MCE. Add it. Signed-off-by:
-
Yinghai Lu authored
The MCE tolerance levels control whether we panic on a machine check or do something else like generating a signal and logging error information. This is controlled by the mce=<level> command line parameter. However, if panic_on_oops is set, it will force a panic for such an MCE even though the user didn't want to. So don't check panic_on_oops in the severity grading anymore. One of the use cases for that is recovery from uncorrectable errors with mce=2. [ Boris: rewrite commit message. ] Signed-off-by:
Yinghai Lu <yinghai.lu@oracle.com> Acked-by:
-
- 05 Nov, 2016 1 commit
-
-
Linus Torvalds authored
-
