| EDAC - Error Detection And Correction | |
| Written by Doug Thompson <norsk5@xmission.com> | |
| 7 Dec 2005 | |
| EDAC was written by: | |
| Thayne Harbaugh, | |
| modified by Dave Peterson, Doug Thompson, et al, | |
| from the bluesmoke.sourceforge.net project. | |
| ============================================================================ | |
| EDAC PURPOSE | |
| The 'edac' kernel module goal is to detect and report errors that occur | |
| within the computer system. In the initial release, memory Correctable Errors | |
| (CE) and Uncorrectable Errors (UE) are the primary errors being harvested. | |
| Detecting CE events, then harvesting those events and reporting them, | |
| CAN be a predictor of future UE events. With CE events, the system can | |
| continue to operate, but with less safety. Preventive maintenance and | |
| proactive part replacement of memory DIMMs exhibiting CEs can reduce | |
| the likelihood of the dreaded UE events and system 'panics'. | |
| In addition, PCI Bus Parity and SERR Errors are scanned for on PCI devices | |
| in order to determine if errors are occurring on data transfers. | |
| The presence of PCI Parity errors must be examined with a grain of salt. | |
| There are several add-in adapters that do NOT follow the PCI specification | |
| with regards to Parity generation and reporting. The specification says | |
| the vendor should tie the parity status bits to 0 if they do not intend | |
| to generate parity. Some vendors do not do this, and thus the parity bit | |
| can "float" giving false positives. | |
| [There are patches in the kernel queue which will allow for storage of | |
| quirks of PCI devices reporting false parity positives. The 2.6.18 | |
| kernel should have those patches included. When that becomes available, | |
| then EDAC will be patched to utilize that information to "skip" such | |
| devices.] | |
| EDAC will have future error detectors that will be integrated with | |
| EDAC or added to it, in the following list: | |
| MCE Machine Check Exception | |
| MCA Machine Check Architecture | |
| NMI NMI notification of ECC errors | |
| MSRs Machine Specific Register error cases | |
| and other mechanisms. | |
| These errors are usually bus errors, ECC errors, thermal throttling | |
| and the like. | |
| ============================================================================ | |
| EDAC VERSIONING | |
| EDAC is composed of a "core" module (edac_mc.ko) and several Memory | |
| Controller (MC) driver modules. On a given system, the CORE | |
| is loaded and one MC driver will be loaded. Both the CORE and | |
| the MC driver have individual versions that reflect current release | |
| level of their respective modules. Thus, to "report" on what version | |
| a system is running, one must report both the CORE's and the | |
| MC driver's versions. | |
| LOADING | |
| If 'edac' was statically linked with the kernel then no loading is | |
| necessary. If 'edac' was built as modules then simply modprobe the | |
| 'edac' pieces that you need. You should be able to modprobe | |
| hardware-specific modules and have the dependencies load the necessary core | |
| modules. | |
| Example: | |
| $> modprobe amd76x_edac | |
| loads both the amd76x_edac.ko memory controller module and the edac_mc.ko | |
| core module. | |
| ============================================================================ | |
| EDAC sysfs INTERFACE | |
| EDAC presents a 'sysfs' interface for control, reporting and attribute | |
| reporting purposes. | |
| EDAC lives in the /sys/devices/system/edac directory. Within this directory | |
| there currently reside 2 'edac' components: | |
| mc memory controller(s) system | |
| pci PCI control and status system | |
| ============================================================================ | |
| Memory Controller (mc) Model | |
| First a background on the memory controller's model abstracted in EDAC. | |
| Each 'mc' device controls a set of DIMM memory modules. These modules are | |
| laid out in a Chip-Select Row (csrowX) and Channel table (chX). There can | |
| be multiple csrows and multiple channels. | |
| Memory controllers allow for several csrows, with 8 csrows being a typical value. | |
| Yet, the actual number of csrows depends on the electrical "loading" | |
| of a given motherboard, memory controller and DIMM characteristics. | |
| Dual channels allows for 128 bit data transfers to the CPU from memory. | |
| Some newer chipsets allow for more than 2 channels, like Fully Buffered DIMMs | |
| (FB-DIMMs). The following example will assume 2 channels: | |
| Channel 0 Channel 1 | |
| =================================== | |
| csrow0 | DIMM_A0 | DIMM_B0 | | |
| csrow1 | DIMM_A0 | DIMM_B0 | | |
| =================================== | |
| =================================== | |
| csrow2 | DIMM_A1 | DIMM_B1 | | |
| csrow3 | DIMM_A1 | DIMM_B1 | | |
| =================================== | |
| In the above example table there are 4 physical slots on the motherboard | |
| for memory DIMMs: | |
| DIMM_A0 | |
| DIMM_B0 | |
| DIMM_A1 | |
| DIMM_B1 | |
| Labels for these slots are usually silk screened on the motherboard. Slots | |
| labeled 'A' are channel 0 in this example. Slots labeled 'B' | |
| are channel 1. Notice that there are two csrows possible on a | |
| physical DIMM. These csrows are allocated their csrow assignment | |
| based on the slot into which the memory DIMM is placed. Thus, when 1 DIMM | |
| is placed in each Channel, the csrows cross both DIMMs. | |
| Memory DIMMs come single or dual "ranked". A rank is a populated csrow. | |
| Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above | |
| will have 1 csrow, csrow0. csrow1 will be empty. On the other hand, | |
| when 2 dual ranked DIMMs are similarly placed, then both csrow0 and | |
| csrow1 will be populated. The pattern repeats itself for csrow2 and | |
| csrow3. | |
| The representation of the above is reflected in the directory tree | |
| in EDAC's sysfs interface. Starting in directory | |
| /sys/devices/system/edac/mc each memory controller will be represented | |
| by its own 'mcX' directory, where 'X" is the index of the MC. | |
| ..../edac/mc/ | |
| | | |
| |->mc0 | |
| |->mc1 | |
| |->mc2 | |
| .... | |
| Under each 'mcX' directory each 'csrowX' is again represented by a | |
| 'csrowX', where 'X" is the csrow index: | |
| .../mc/mc0/ | |
| | | |
| |->csrow0 | |
| |->csrow2 | |
| |->csrow3 | |
| .... | |
| Notice that there is no csrow1, which indicates that csrow0 is | |
| composed of a single ranked DIMMs. This should also apply in both | |
| Channels, in order to have dual-channel mode be operational. Since | |
| both csrow2 and csrow3 are populated, this indicates a dual ranked | |
| set of DIMMs for channels 0 and 1. | |
| Within each of the 'mc','mcX' and 'csrowX' directories are several | |
| EDAC control and attribute files. | |
| ============================================================================ | |
| DIRECTORY 'mc' | |
| In directory 'mc' are EDAC system overall control and attribute files: | |
| Panic on UE control file: | |
| 'panic_on_ue' | |
| An uncorrectable error will cause a machine panic. This is usually | |
| desirable. It is a bad idea to continue when an uncorrectable error | |
| occurs - it is indeterminate what was uncorrected and the operating | |
| system context might be so mangled that continuing will lead to further | |
| corruption. If the kernel has MCE configured, then EDAC will never | |
| notice the UE. | |
| LOAD TIME: module/kernel parameter: panic_on_ue=[0|1] | |
| RUN TIME: echo "1" >/sys/devices/system/edac/mc/panic_on_ue | |
| Log UE control file: | |
| 'log_ue' | |
| Generate kernel messages describing uncorrectable errors. These errors | |
| are reported through the system message log system. UE statistics | |
| will be accumulated even when UE logging is disabled. | |
| LOAD TIME: module/kernel parameter: log_ue=[0|1] | |
| RUN TIME: echo "1" >/sys/devices/system/edac/mc/log_ue | |
| Log CE control file: | |
| 'log_ce' | |
| Generate kernel messages describing correctable errors. These | |
| errors are reported through the system message log system. | |
| CE statistics will be accumulated even when CE logging is disabled. | |
| LOAD TIME: module/kernel parameter: log_ce=[0|1] | |
| RUN TIME: echo "1" >/sys/devices/system/edac/mc/log_ce | |
| Polling period control file: | |
| 'poll_msec' | |
| The time period, in milliseconds, for polling for error information. | |
| Too small a value wastes resources. Too large a value might delay | |
| necessary handling of errors and might loose valuable information for | |
| locating the error. 1000 milliseconds (once each second) is the current | |
| default. Systems which require all the bandwidth they can get, may | |
| increase this. | |
| LOAD TIME: module/kernel parameter: poll_msec=[0|1] | |
| RUN TIME: echo "1000" >/sys/devices/system/edac/mc/poll_msec | |
| ============================================================================ | |
| 'mcX' DIRECTORIES | |
| In 'mcX' directories are EDAC control and attribute files for | |
| this 'X" instance of the memory controllers: | |
| Counter reset control file: | |
| 'reset_counters' | |
| This write-only control file will zero all the statistical counters | |
| for UE and CE errors. Zeroing the counters will also reset the timer | |
| indicating how long since the last counter zero. This is useful | |
| for computing errors/time. Since the counters are always reset at | |
| driver initialization time, no module/kernel parameter is available. | |
| RUN TIME: echo "anything" >/sys/devices/system/edac/mc/mc0/counter_reset | |
| This resets the counters on memory controller 0 | |
| Seconds since last counter reset control file: | |
| 'seconds_since_reset' | |
| This attribute file displays how many seconds have elapsed since the | |
| last counter reset. This can be used with the error counters to | |
| measure error rates. | |
| Memory Controller name attribute file: | |
| 'mc_name' | |
| This attribute file displays the type of memory controller | |
| that is being utilized. | |
| Total memory managed by this memory controller attribute file: | |
| 'size_mb' | |
| This attribute file displays, in count of megabytes, of memory | |
| that this instance of memory controller manages. | |
| Total Uncorrectable Errors count attribute file: | |
| 'ue_count' | |
| This attribute file displays the total count of uncorrectable | |
| errors that have occurred on this memory controller. If panic_on_ue | |
| is set this counter will not have a chance to increment, | |
| since EDAC will panic the system. | |
| Total UE count that had no information attribute fileY: | |
| 'ue_noinfo_count' | |
| This attribute file displays the number of UEs that | |
| have occurred have occurred with no informations as to which DIMM | |
| slot is having errors. | |
| Total Correctable Errors count attribute file: | |
| 'ce_count' | |
| This attribute file displays the total count of correctable | |
| errors that have occurred on this memory controller. This | |
| count is very important to examine. CEs provide early | |
| indications that a DIMM is beginning to fail. This count | |
| field should be monitored for non-zero values and report | |
| such information to the system administrator. | |
| Total Correctable Errors count attribute file: | |
| 'ce_noinfo_count' | |
| This attribute file displays the number of CEs that | |
| have occurred wherewith no informations as to which DIMM slot | |
| is having errors. Memory is handicapped, but operational, | |
| yet no information is available to indicate which slot | |
| the failing memory is in. This count field should be also | |
| be monitored for non-zero values. | |
| Device Symlink: | |
| 'device' | |
| Symlink to the memory controller device | |
| ============================================================================ | |
| 'csrowX' DIRECTORIES | |
| In the 'csrowX' directories are EDAC control and attribute files for | |
| this 'X" instance of csrow: | |
| Total Uncorrectable Errors count attribute file: | |
| 'ue_count' | |
| This attribute file displays the total count of uncorrectable | |
| errors that have occurred on this csrow. If panic_on_ue is set | |
| this counter will not have a chance to increment, since EDAC | |
| will panic the system. | |
| Total Correctable Errors count attribute file: | |
| 'ce_count' | |
| This attribute file displays the total count of correctable | |
| errors that have occurred on this csrow. This | |
| count is very important to examine. CEs provide early | |
| indications that a DIMM is beginning to fail. This count | |
| field should be monitored for non-zero values and report | |
| such information to the system administrator. | |
| Total memory managed by this csrow attribute file: | |
| 'size_mb' | |
| This attribute file displays, in count of megabytes, of memory | |
| that this csrow contains. | |
| Memory Type attribute file: | |
| 'mem_type' | |
| This attribute file will display what type of memory is currently | |
| on this csrow. Normally, either buffered or unbuffered memory. | |
| Examples: | |
| Registered-DDR | |
| Unbuffered-DDR | |
| EDAC Mode of operation attribute file: | |
| 'edac_mode' | |
| This attribute file will display what type of Error detection | |
| and correction is being utilized. | |
| Device type attribute file: | |
| 'dev_type' | |
| This attribute file will display what type of DRAM device is | |
| being utilized on this DIMM. | |
| Examples: | |
| x1 | |
| x2 | |
| x4 | |
| x8 | |
| Channel 0 CE Count attribute file: | |
| 'ch0_ce_count' | |
| This attribute file will display the count of CEs on this | |
| DIMM located in channel 0. | |
| Channel 0 UE Count attribute file: | |
| 'ch0_ue_count' | |
| This attribute file will display the count of UEs on this | |
| DIMM located in channel 0. | |
| Channel 0 DIMM Label control file: | |
| 'ch0_dimm_label' | |
| This control file allows this DIMM to have a label assigned | |
| to it. With this label in the module, when errors occur | |
| the output can provide the DIMM label in the system log. | |
| This becomes vital for panic events to isolate the | |
| cause of the UE event. | |
| DIMM Labels must be assigned after booting, with information | |
| that correctly identifies the physical slot with its | |
| silk screen label. This information is currently very | |
| motherboard specific and determination of this information | |
| must occur in userland at this time. | |
| Channel 1 CE Count attribute file: | |
| 'ch1_ce_count' | |
| This attribute file will display the count of CEs on this | |
| DIMM located in channel 1. | |
| Channel 1 UE Count attribute file: | |
| 'ch1_ue_count' | |
| This attribute file will display the count of UEs on this | |
| DIMM located in channel 0. | |
| Channel 1 DIMM Label control file: | |
| 'ch1_dimm_label' | |
| This control file allows this DIMM to have a label assigned | |
| to it. With this label in the module, when errors occur | |
| the output can provide the DIMM label in the system log. | |
| This becomes vital for panic events to isolate the | |
| cause of the UE event. | |
| DIMM Labels must be assigned after booting, with information | |
| that correctly identifies the physical slot with its | |
| silk screen label. This information is currently very | |
| motherboard specific and determination of this information | |
| must occur in userland at this time. | |
| ============================================================================ | |
| SYSTEM LOGGING | |
| If logging for UEs and CEs are enabled then system logs will have | |
| error notices indicating errors that have been detected: | |
| EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0, | |
| channel 1 "DIMM_B1": amd76x_edac | |
| EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0, | |
| channel 1 "DIMM_B1": amd76x_edac | |
| The structure of the message is: | |
| the memory controller (MC0) | |
| Error type (CE) | |
| memory page (0x283) | |
| offset in the page (0xce0) | |
| the byte granularity (grain 8) | |
| or resolution of the error | |
| the error syndrome (0xb741) | |
| memory row (row 0) | |
| memory channel (channel 1) | |
| DIMM label, if set prior (DIMM B1 | |
| and then an optional, driver-specific message that may | |
| have additional information. | |
| Both UEs and CEs with no info will lack all but memory controller, | |
| error type, a notice of "no info" and then an optional, | |
| driver-specific error message. | |
| ============================================================================ | |
| PCI Bus Parity Detection | |
| On Header Type 00 devices the primary status is looked at | |
| for any parity error regardless of whether Parity is enabled on the | |
| device. (The spec indicates parity is generated in some cases). | |
| On Header Type 01 bridges, the secondary status register is also | |
| looked at to see if parity occurred on the bus on the other side of | |
| the bridge. | |
| SYSFS CONFIGURATION | |
| Under /sys/devices/system/edac/pci are control and attribute files as follows: | |
| Enable/Disable PCI Parity checking control file: | |
| 'check_pci_parity' | |
| This control file enables or disables the PCI Bus Parity scanning | |
| operation. Writing a 1 to this file enables the scanning. Writing | |
| a 0 to this file disables the scanning. | |
| Enable: | |
| echo "1" >/sys/devices/system/edac/pci/check_pci_parity | |
| Disable: | |
| echo "0" >/sys/devices/system/edac/pci/check_pci_parity | |
| Panic on PCI PARITY Error: | |
| 'panic_on_pci_parity' | |
| This control files enables or disables panicking when a parity | |
| error has been detected. | |
| module/kernel parameter: panic_on_pci_parity=[0|1] | |
| Enable: | |
| echo "1" >/sys/devices/system/edac/pci/panic_on_pci_parity | |
| Disable: | |
| echo "0" >/sys/devices/system/edac/pci/panic_on_pci_parity | |
| Parity Count: | |
| 'pci_parity_count' | |
| This attribute file will display the number of parity errors that | |
| have been detected. | |
| ======================================================================= |