|  | 
 |  | 
 | 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. | 
 |  | 
 |  | 
 |  | 
 | ======================================================================= |