summaryrefslogtreecommitdiffstats
path: root/drivers/edac/ghes_edac.c
Commit message (Collapse)AuthorAgeFilesLines
* EDAC, ghes: Make platform-based whitelisting x86-onlyBorislav Petkov2018-05-211-5/+9
| | | | | | | | | | | | | | | | ARM machines all have DMI tables so if they request hw error reporting through GHES, then the driver should be able to detect DIMMs and report errors successfully (famous last words :)). Make the platform-based list x86-specific so that ghes_edac can load on ARM. Reported-by: Qiang Zheng <zhengqiang10@huawei.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: James Morse <james.morse@arm.com> Tested-by: James Morse <james.morse@arm.com> Tested-by: Qiang Zheng <zhengqiang10@huawei.com> Link: https://lkml.kernel.org/r/1526039543-180996-1-git-send-email-zhengqiang10@huawei.com
* EDAC, ghes: Use BIT() macroBorislav Petkov2018-05-121-14/+13
| | | | | | | | | | | ... for improved readability. Also, add a local mask variable for the same reason. No functional changes. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Toshi Kani <toshi.kani@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
* EDAC, ghes: Add DDR4 and NVDIMM memory typesToshi Kani2018-05-121-1/+11
| | | | | | | | | | | | | | | The ghes_edac driver obtains memory type from SMBIOS type 17, but it does not recognize DDR4 and NVDIMM types. Add support of DDR4 and NVDIMM types. NVDIMM type is denoted by memory type DDR3/4 and non-volatile. Reported-by: Robert Elliott <elliott@hpe.com> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20180509222030.9299-1-toshi.kani@hpe.com Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC, ghes: Remove unused argument to ghes_edac_report_mem_error()Alexandru Gagniuc2018-05-121-2/+1
| | | | | | | | | | | | The use of the @ghes argument was removed in a previous commit, but function signature was not updated to reflect this. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Cc: linux-acpi@vger.kernel.org Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20180430213358.8319-1-mr.nuke.me@gmail.com Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC, ghes: Add a null pointer check in ghes_edac_unregister()Sughosh Ganu2018-05-021-0/+3
| | | | | | | | | | | | | | Add a null check for ghes_pvt, before dereferencing it. The pointer could still be null in case the return path is taken before initialising ghes_pvt in the registration function. Reviewed-by: Toshi Kani <toshi.kani@hpe.com> Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: lkml <linux-kernel@vger.kernel.org> Link: http://lkml.kernel.org/r/1524737809-24475-1-git-send-email-sughosh.ganu@arm.com Signed-off-by: Borislav Petkov <bp@suse.de>
* ghes, EDAC: Fix ghes_edac registrationBorislav Petkov2018-05-021-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Tony reported seeing "Internal error: Can't find EDAC structure" when injecting correctable errors due to the fact that ghes_edac would still load even if the whitelist won't hit. Drop the pr_err() in ghes_edac_report_mem_error() for now due to the hacky way how ghes_edac depends on ghes.c. While at it, make ghes_edac_register() return an error if it doesn't hit in the whitelist as it is the only sensible thing to do in that situation. Furthermore, move the call to it to happen last in ghes_probe() so that GHES initializing properly does not depend on ghes_edac init at all as latter is only reporting errors and not required for GHES's proper functioning. Reviewed-by: Toshi Kani <toshi.kani@hpe.com> Tested-by: Sughosh Ganu <sughosh.ganu@arm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/20180420182015.zao3olss4tvvlxki@agluck-desk
* EDAC, ghes: Add platform checkToshi Kani2017-09-251-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This driver obtains error info from firmware interfaces (APEI), which are not properly implemented on many platforms, as the driver says on load: This EDAC driver relies on BIOS to enumerate memory and get error reports. Unfortunately, not all BIOSes reflect the memory layout correctly. So, the end result of using this driver varies from vendor to vendor. If you find incorrect reports, please contact your hardware vendor to correct its BIOS. To get out from this situation, add a platform check to selectively enable the driver on platforms that are known to have proper APEI firmware implementation. "ghes_edac.force_load=1" skips this platform check. [1]: https://lkml.kernel.org/r/cover.1360931635.git.mchehab@redhat.com Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-acpi@vger.kernel.org Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170823225447.15608-4-toshi.kani@hpe.com Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC, ghes: Model a single, logical memory controllerBorislav Petkov2017-09-251-65/+51
| | | | | | | | | | | | | | We're enumerating the DIMMs through a DMI walk and since we can't get any more detailed topological information about which DIMMs belong to which memory controller, convert it to a single, logical controller which contains all the DIMMs. The error reporting path from GHES ghes_edac_report_mem_error() doesn't get called in NMI context but add a warning about it to catch any changes in the future as if so, our locking scheme will be insufficient then. Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC, ghes: Remove symbol exportsBorislav Petkov2017-09-251-3/+0
| | | | | | They're called from builtin code so no need for the exports. Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC: Get rid of mci->mod_verBorislav Petkov2017-07-171-3/+0
| | | | | | | | | | | | | | | | | | | | | | | It is a write-only variable so get rid of it. Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Robert Richter <rric@kernel.org> Acked-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Thor Thayer <thor.thayer@linux.intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Mark Gross <mark.gross@intel.com> Cc: Tim Small <tim@buttersideup.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Cc: Jason Baron <jbaron@akamai.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Daney <david.daney@cavium.com> Cc: Loc Ho <lho@apm.com> Cc: linux-edac@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@linux-mips.org
* edac: rename edac_core.h to edac_mc.hMauro Carvalho Chehab2016-12-151-1/+1
| | | | | | | Now, all left at edac_core.h are at drivers/edac/edac_mc.c, so rename it to edac_mc.h. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* EDAC: Fix PAGES_TO_MiB macro misuseTan Xiaojun2015-10-221-1/+1
| | | | | | | | | | | The PAGES_TO_MiB macro is used for unit conversion but the trace_mc_event() tracepoint expects a page address. Fix that. Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1445341538-24271-1-git-send-email-tanxiaojun@huawei.com Signed-off-by: Borislav Petkov <bp@suse.de>
* EDAC, ghes_edac: Remove redundant memory_type arrayAravind Gopalakrishnan2015-09-231-21/+1
| | | | | | | | | | | We already have edac_mem_types[] that enumerates the different kinds of memory. So, use that and remove the redundant memory_type[] array here. Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1442436811-23382-2-git-send-email-Aravind.Gopalakrishnan@amd.com Signed-off-by: Borislav Petkov <bp@suse.de>
* ghes_edac: Use snprintf() to silence a static checker warningDan Carpenter2014-11-111-2/+2
| | | | | | | | | | | | | | | | My static checker complains because the "e->location" has up to 256 characters but we are copying it into the "pvt->detail_location" which only has space for 240 characters. That's not counting the surrounding text and the "e->other_detail" string which can be over 80 characters long. I am not familiar with this code but presumably it normally works. Let's add a limit though for safety. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Link: http://lkml.kernel.org/r/20140801082514.GD28869@mwanda Signed-off-by: Borislav Petkov <bp@suse.de>
* [media, edac] Change my email addressMauro Carvalho Chehab2014-02-071-1/+1
| | | | | | | | There are several left overs with my old email address. Remove their occurrences and add myself at CREDITS, to allow people to be able to reach me on my new addresses. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* EDAC, GHES: Update ghes error record infoChen, Gong2013-10-231-0/+11
| | | | | | | | | | In latest UEFI spec(by now it's 2.4) there are some new fields for memory error reporting. Add these new fields for ghes_edac interface. Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* ACPI, APEI, CPER: Add UEFI 2.4 support for memory errorChen, Gong2013-10-231-3/+2
| | | | | | | | | | | | | | In latest UEFI spec(by now it is 2.4) memory error definition for CPER (UEFI 2.4 Appendix N Common Platform Error Record) adds some new fields. These fields help people to locate memory error to an actual DIMM location. Original-author: Tony Luck <tony.luck@intel.com> Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Reviewed-by: Borislav Petkov <bp@suse.de> Reviewed-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* ghes_edac: fix to use list_for_each_entry_safe() when delete list itemsWei Yongjun2013-02-261-2/+2
| | | | | | | | | Since we will remove items off the list using list_del() we need to use a safe version of the list_for_each_entry() macro aptly named list_for_each_entry_safe(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: Fix RAS tracingMauro Carvalho Chehab2013-02-251-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the current version of CPER, there's no way to associate an error with the memory error. So, the error location in EDAC layers is unused. As CPER has its own idea about memory architectural layers, just output whatever is there inside the driver's detail at the RAS tracepoint. The EDAC location keeps untouched, in the case that, in some future, we could actually map the error into the dimm labels. Now, the error message: [ 72.396625] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 [ 72.396627] {1}[Hardware Error]: APEI generic hardware error status [ 72.396628] {1}[Hardware Error]: severity: 2, corrected [ 72.396630] {1}[Hardware Error]: section: 0, severity: 2, corrected [ 72.396632] {1}[Hardware Error]: flags: 0x01 [ 72.396634] {1}[Hardware Error]: primary [ 72.396635] {1}[Hardware Error]: section_type: memory error [ 72.396637] {1}[Hardware Error]: error_status: 0x0000000000000400 [ 72.396638] {1}[Hardware Error]: node: 3 [ 72.396639] {1}[Hardware Error]: card: 0 [ 72.396640] {1}[Hardware Error]: module: 0 [ 72.396641] {1}[Hardware Error]: device: 0 [ 72.396643] {1}[Hardware Error]: error_type: 18, unknown [ 72.396666] EDAC MC0: 1 CE reserved error (18) on unknown label (node:3 card:0 module:0 page:0x0 offset:0x0 grain:0 syndrome:0x0 - status(0x0000000000000400): Storage error in DRAM memory) Is properly represented on the trace event: kworker/0:2-584 [000] .... 72.396657: mc_event: 1 Corrected error: reserved error (18) on unknown label (mc:0 location:-1:-1:-1 address:0x00000000 grain:1 syndrome:0x00000000 APEI location: node:3 card:0 module:0 status(0x0000000000000400): Storage error in DRAM memory) Tested on a 4 sockets E5-4650 Sandy Bridge machine. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: Make it compliant with UEFI spec 2.3.1Mauro Carvalho Chehab2013-02-251-15/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI spec defines the memory error types ans the bits that validate each field on the memory error record, at Appendix N om items N.2.5 (Memory Error Section) and N.2.11 (Error Status). Make the error description compliant with it, only showing the valid fields. The EDAC error log is now properly reporting the error: [ 281.556854] mce: [Hardware Error]: Machine check events logged [ 281.557042] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 [ 281.557044] {2}[Hardware Error]: APEI generic hardware error status [ 281.557046] {2}[Hardware Error]: severity: 2, corrected [ 281.557048] {2}[Hardware Error]: section: 0, severity: 2, corrected [ 281.557050] {2}[Hardware Error]: flags: 0x01 [ 281.557052] {2}[Hardware Error]: primary [ 281.557053] {2}[Hardware Error]: section_type: memory error [ 281.557055] {2}[Hardware Error]: error_status: 0x0000000000000400 [ 281.557056] {2}[Hardware Error]: node: 3 [ 281.557057] {2}[Hardware Error]: card: 0 [ 281.557058] {2}[Hardware Error]: module: 1 [ 281.557059] {2}[Hardware Error]: device: 0 [ 281.557061] {2}[Hardware Error]: error_type: 18, unknown [ 281.557067] EDAC DEBUG: ghes_edac_report_mem_error: error validation_bits: 0x000040b9 [ 281.557084] EDAC MC0: 1 CE reserved error (18) on unknown label (node:3 card:0 module:1 page:0x0 offset:0x0 grain:0 syndrome:0x0 - status(0x0000000000000400): Storage error in DRAM memory) Tested on a 4 CPUs E5-4650 Sandy Bridge machine. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: Improve driver's printk messagesMauro Carvalho Chehab2013-02-251-10/+26
| | | | | | | | | | | | | | | | | | Provide a better infrastructure for printk's inside the driver: - use edac_dbg() for debug messages; - standardize the usage of pr_info(); - provide warning about the risk of relying on this driver. While here, changes the size of a fake memory to 1 page. This is as good or as bad as 1000 pages, but it is easier for userspace to detect, as I don't expect that any machine implementing GHES would provide just 1 page available ;) Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Conflicts: drivers/edac/ghes_edac.c
* ghes_edac: Don't credit the same memory dimm twiceMauro Carvalho Chehab2013-02-251-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On my tests on a 4xE5-4650 CPU's system, the GHES EDAC driver is called twice. As the SMBIOS DMI enumeration call will seek for the entire DIMM sockets in the system, on this machine, equipped with 128 GB of RAM, the memory is displayed twice: +-----------------------+ | mc0 | mc1 | ----------+-----------------------+ memory45: | 8192 MB | 8192 MB | memory44: | 0 MB | 0 MB | ----------+-----------------------+ memory43: | 0 MB | 0 MB | memory42: | 8192 MB | 8192 MB | ----------+-----------------------+ memory41: | 0 MB | 0 MB | memory40: | 0 MB | 0 MB | ----------+-----------------------+ memory39: | 8192 MB | 8192 MB | memory38: | 0 MB | 0 MB | ----------+-----------------------+ memory37: | 0 MB | 0 MB | memory36: | 8192 MB | 8192 MB | ----------+-----------------------+ memory35: | 0 MB | 0 MB | memory34: | 0 MB | 0 MB | ----------+-----------------------+ memory33: | 8192 MB | 8192 MB | memory32: | 0 MB | 0 MB | ----------+-----------------------+ memory31: | 0 MB | 0 MB | memory30: | 8192 MB | 8192 MB | ----------+-----------------------+ memory29: | 0 MB | 0 MB | memory28: | 0 MB | 0 MB | ----------+-----------------------+ memory27: | 8192 MB | 8192 MB | memory26: | 0 MB | 0 MB | ----------+-----------------------+ memory25: | 0 MB | 0 MB | memory24: | 8192 MB | 8192 MB | ----------+-----------------------+ memory23: | 0 MB | 0 MB | memory22: | 0 MB | 0 MB | ----------+-----------------------+ memory21: | 8192 MB | 8192 MB | memory20: | 0 MB | 0 MB | ----------+-----------------------+ memory19: | 0 MB | 0 MB | memory18: | 8192 MB | 8192 MB | ----------+-----------------------+ memory17: | 0 MB | 0 MB | memory16: | 0 MB | 0 MB | ----------+-----------------------+ memory15: | 8192 MB | 8192 MB | memory14: | 0 MB | 0 MB | ----------+-----------------------+ memory13: | 0 MB | 0 MB | memory12: | 8192 MB | 8192 MB | ----------+-----------------------+ memory11: | 0 MB | 0 MB | memory10: | 0 MB | 0 MB | ----------+-----------------------+ memory9: | 8192 MB | 8192 MB | memory8: | 0 MB | 0 MB | ----------+-----------------------+ memory7: | 0 MB | 0 MB | memory6: | 8192 MB | 8192 MB | ----------+-----------------------+ memory5: | 0 MB | 0 MB | memory4: | 0 MB | 0 MB | ----------+-----------------------+ memory3: | 8192 MB | 8192 MB | memory2: | 0 MB | 0 MB | ----------+-----------------------+ memory1: | 0 MB | 0 MB | memory0: | 8192 MB | 8192 MB | ----------+-----------------------+ Total sum of 256 GB. As there's no reliable way to credit DIMMS to the right memory controller, just put everything on memory controller 0 (with should always exist). Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: do a better job of filling EDAC DIMM infoMauro Carvalho Chehab2013-02-251-12/+180
| | | | | | | Instead of just faking a random value for the DIMM data, get the information that it is available via DMI table. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: add support for reporting errors via EDACMauro Carvalho Chehab2013-02-251-2/+54
| | | | | | | Now that the EDAC core is capable of just forward the errors via the userspace API, add a report mechanism for the GHES errors. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ghes_edac: Register at EDAC core the BIOS reportMauro Carvalho Chehab2013-02-251-0/+114
Register GHES at EDAC MC core, in order to avoid other drivers to also handle errors and mangle with error data. The edac core will warrant that just one driver will be used, so the first one to register (BIOS first) will be the one that will be reporting the hardware errors. For now, the EDAC driver does nothing but to register at the EDAC core, preventing the hardware-driven mechanism to interfere with GHES. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 22:22:27 +0000