About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / edac.txt




Custom Search

Based on kernel version 4.3. Page generated on 2015-11-02 12:48 EST.

1	EDAC - Error Detection And Correction
2	=====================================
3	
4	"bluesmoke" was the name for this device driver when it was "out-of-tree"
5	and maintained at sourceforge.net.  When it was pushed into 2.6.16 for the
6	first time, it was renamed to 'EDAC'.
7	
8	PURPOSE
9	-------
10	
11	The 'edac' kernel module's goal is to detect and report hardware errors
12	that occur within the computer system running under linux.
13	
14	MEMORY
15	------
16	
17	Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the
18	primary errors being harvested. These types of errors are harvested by
19	the 'edac_mc' device.
20	
21	Detecting CE events, then harvesting those events and reporting them,
22	*can* but must not necessarily be a predictor of future UE events. With
23	CE events only, the system can and will continue to operate as no data
24	has been damaged yet.
25	
26	However, preventive maintenance and proactive part replacement of memory
27	DIMMs exhibiting CEs can reduce the likelihood of the dreaded UE events
28	and system panics.
29	
30	OTHER HARDWARE ELEMENTS
31	-----------------------
32	
33	A new feature for EDAC, the edac_device class of device, was added in
34	the 2.6.23 version of the kernel.
35	
36	This new device type allows for non-memory type of ECC hardware detectors
37	to have their states harvested and presented to userspace via the sysfs
38	interface.
39	
40	Some architectures have ECC detectors for L1, L2 and L3 caches,
41	along with DMA engines, fabric switches, main data path switches,
42	interconnections, and various other hardware data paths. If the hardware
43	reports it, then a edac_device device probably can be constructed to
44	harvest and present that to userspace.
45	
46	
47	PCI BUS SCANNING
48	----------------
49	
50	In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors
51	in order to determine if errors are occurring during data transfers.
52	
53	The presence of PCI Parity errors must be examined with a grain of salt.
54	There are several add-in adapters that do *not* follow the PCI specification
55	with regards to Parity generation and reporting. The specification says
56	the vendor should tie the parity status bits to 0 if they do not intend
57	to generate parity.  Some vendors do not do this, and thus the parity bit
58	can "float" giving false positives.
59	
60	There is a PCI device attribute located in sysfs that is checked by
61	the EDAC PCI scanning code. If that attribute is set, PCI parity/error
62	scanning is skipped for that device. The attribute is:
63	
64		broken_parity_status
65	
66	and is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for
67	PCI devices.
68	
69	
70	VERSIONING
71	----------
72	
73	EDAC is composed of a "core" module (edac_core.ko) and several Memory
74	Controller (MC) driver modules. On a given system, the CORE is loaded
75	and one MC driver will be loaded. Both the CORE and the MC driver (or
76	edac_device driver) have individual versions that reflect current
77	release level of their respective modules.
78	
79	Thus, to "report" on what version a system is running, one must report
80	both the CORE's and the MC driver's versions.
81	
82	
83	LOADING
84	-------
85	
86	If 'edac' was statically linked with the kernel then no loading
87	is necessary. If 'edac' was built as modules then simply modprobe
88	the 'edac' pieces that you need. You should be able to modprobe
89	hardware-specific modules and have the dependencies load the necessary
90	core modules.
91	
92	Example:
93	
94	$> modprobe amd76x_edac
95	
96	loads both the amd76x_edac.ko memory controller module and the edac_mc.ko
97	core module.
98	
99	
100	SYSFS INTERFACE
101	---------------
102	
103	EDAC presents a 'sysfs' interface for control and reporting purposes. It
104	lives in the /sys/devices/system/edac directory.
105	
106	Within this directory there currently reside 2 components:
107	
108		mc	memory controller(s) system
109		pci	PCI control and status system
110	
111	
112	
113	Memory Controller (mc) Model
114	----------------------------
115	
116	Each 'mc' device controls a set of DIMM memory modules. These modules
117	are laid out in a Chip-Select Row (csrowX) and Channel table (chX).
118	There can be multiple csrows and multiple channels.
119	
120	Memory controllers allow for several csrows, with 8 csrows being a
121	typical value. Yet, the actual number of csrows depends on the layout of
122	a given motherboard, memory controller and DIMM characteristics.
123	
124	Dual channels allows for 128 bit data transfers to/from the CPU from/to
125	memory. Some newer chipsets allow for more than 2 channels, like Fully
126	Buffered DIMMs (FB-DIMMs). The following example will assume 2 channels:
127	
128	
129			Channel 0	Channel 1
130		===================================
131		csrow0	| DIMM_A0	| DIMM_B0 |
132		csrow1	| DIMM_A0	| DIMM_B0 |
133		===================================
134	
135		===================================
136		csrow2	| DIMM_A1	| DIMM_B1 |
137		csrow3	| DIMM_A1	| DIMM_B1 |
138		===================================
139	
140	In the above example table there are 4 physical slots on the motherboard
141	for memory DIMMs:
142	
143		DIMM_A0
144		DIMM_B0
145		DIMM_A1
146		DIMM_B1
147	
148	Labels for these slots are usually silk-screened on the motherboard.
149	Slots labeled 'A' are channel 0 in this example. Slots labeled 'B' are
150	channel 1. Notice that there are two csrows possible on a physical DIMM.
151	These csrows are allocated their csrow assignment based on the slot into
152	which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
153	Channel, the csrows cross both DIMMs.
154	
155	Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
156	Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
157	will have 1 csrow, csrow0. csrow1 will be empty. On the other hand,
158	when 2 dual ranked DIMMs are similarly placed, then both csrow0 and
159	csrow1 will be populated. The pattern repeats itself for csrow2 and
160	csrow3.
161	
162	The representation of the above is reflected in the directory
163	tree in EDAC's sysfs interface. Starting in directory
164	/sys/devices/system/edac/mc each memory controller will be represented
165	by its own 'mcX' directory, where 'X' is the index of the MC.
166	
167	
168		..../edac/mc/
169			   |
170			   |->mc0
171			   |->mc1
172			   |->mc2
173			   ....
174	
175	Under each 'mcX' directory each 'csrowX' is again represented by a
176	'csrowX', where 'X' is the csrow index:
177	
178	
179		.../mc/mc0/
180			|
181			|->csrow0
182			|->csrow2
183			|->csrow3
184			....
185	
186	Notice that there is no csrow1, which indicates that csrow0 is composed
187	of a single ranked DIMMs. This should also apply in both Channels, in
188	order to have dual-channel mode be operational. Since both csrow2 and
189	csrow3 are populated, this indicates a dual ranked set of DIMMs for
190	channels 0 and 1.
191	
192	
193	Within each of the 'mcX' and 'csrowX' directories are several EDAC
194	control and attribute files.
195	
196	
197	'mcX' directories
198	-----------------
199	
200	In 'mcX' directories are EDAC control and attribute files for
201	this 'X' instance of the memory controllers.
202	
203	For a description of the sysfs API, please see:
204		Documentation/ABI/testing/sysfs-devices-edac
205	
206	
207	
208	'csrowX' directories
209	--------------------
210	
211	When CONFIG_EDAC_LEGACY_SYSFS is enabled, sysfs will contain the csrowX
212	directories. As this API doesn't work properly for Rambus, FB-DIMMs and
213	modern Intel Memory Controllers, this is being deprecated in favor of
214	dimmX directories.
215	
216	In the 'csrowX' directories are EDAC control and attribute files for
217	this 'X' instance of csrow:
218	
219	
220	Total Uncorrectable Errors count attribute file:
221	
222		'ue_count'
223	
224		This attribute file displays the total count of uncorrectable
225		errors that have occurred on this csrow. If panic_on_ue is set
226		this counter will not have a chance to increment, since EDAC
227		will panic the system.
228	
229	
230	Total Correctable Errors count attribute file:
231	
232		'ce_count'
233	
234		This attribute file displays the total count of correctable
235		errors that have occurred on this csrow. This count is very
236		important to examine. CEs provide early indications that a
237		DIMM is beginning to fail. This count field should be
238		monitored for non-zero values and report such information
239		to the system administrator.
240	
241	
242	Total memory managed by this csrow attribute file:
243	
244		'size_mb'
245	
246		This attribute file displays, in count of megabytes, the memory
247		that this csrow contains.
248	
249	
250	Memory Type attribute file:
251	
252		'mem_type'
253	
254		This attribute file will display what type of memory is currently
255		on this csrow. Normally, either buffered or unbuffered memory.
256		Examples:
257			Registered-DDR
258			Unbuffered-DDR
259	
260	
261	EDAC Mode of operation attribute file:
262	
263		'edac_mode'
264	
265		This attribute file will display what type of Error detection
266		and correction is being utilized.
267	
268	
269	Device type attribute file:
270	
271		'dev_type'
272	
273		This attribute file will display what type of DRAM device is
274		being utilized on this DIMM.
275		Examples:
276			x1
277			x2
278			x4
279			x8
280	
281	
282	Channel 0 CE Count attribute file:
283	
284		'ch0_ce_count'
285	
286		This attribute file will display the count of CEs on this
287		DIMM located in channel 0.
288	
289	
290	Channel 0 UE Count attribute file:
291	
292		'ch0_ue_count'
293	
294		This attribute file will display the count of UEs on this
295		DIMM located in channel 0.
296	
297	
298	Channel 0 DIMM Label control file:
299	
300		'ch0_dimm_label'
301	
302		This control file allows this DIMM to have a label assigned
303		to it. With this label in the module, when errors occur
304		the output can provide the DIMM label in the system log.
305		This becomes vital for panic events to isolate the
306		cause of the UE event.
307	
308		DIMM Labels must be assigned after booting, with information
309		that correctly identifies the physical slot with its
310		silk screen label. This information is currently very
311		motherboard specific and determination of this information
312		must occur in userland at this time.
313	
314	
315	Channel 1 CE Count attribute file:
316	
317		'ch1_ce_count'
318	
319		This attribute file will display the count of CEs on this
320		DIMM located in channel 1.
321	
322	
323	Channel 1 UE Count attribute file:
324	
325		'ch1_ue_count'
326	
327		This attribute file will display the count of UEs on this
328		DIMM located in channel 0.
329	
330	
331	Channel 1 DIMM Label control file:
332	
333		'ch1_dimm_label'
334	
335		This control file allows this DIMM to have a label assigned
336		to it. With this label in the module, when errors occur
337		the output can provide the DIMM label in the system log.
338		This becomes vital for panic events to isolate the
339		cause of the UE event.
340	
341		DIMM Labels must be assigned after booting, with information
342		that correctly identifies the physical slot with its
343		silk screen label. This information is currently very
344		motherboard specific and determination of this information
345		must occur in userland at this time.
346	
347	
348	
349	SYSTEM LOGGING
350	--------------
351	
352	If logging for UEs and CEs is enabled, then system logs will contain
353	information indicating that errors have been detected:
354	
355	EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0,
356	channel 1 "DIMM_B1": amd76x_edac
357	
358	EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0,
359	channel 1 "DIMM_B1": amd76x_edac
360	
361	
362	The structure of the message is:
363		the memory controller			(MC0)
364		Error type				(CE)
365		memory page				(0x283)
366		offset in the page			(0xce0)
367		the byte granularity 			(grain 8)
368			or resolution of the error
369		the error syndrome			(0xb741)
370		memory row				(row 0)
371		memory channel				(channel 1)
372		DIMM label, if set prior		(DIMM B1
373		and then an optional, driver-specific message that may
374			have additional information.
375	
376	Both UEs and CEs with no info will lack all but memory controller, error
377	type, a notice of "no info" and then an optional, driver-specific error
378	message.
379	
380	
381	PCI Bus Parity Detection
382	------------------------
383	
384	On Header Type 00 devices, the primary status is looked at for any
385	parity error regardless of whether parity is enabled on the device or
386	not. (The spec indicates parity is generated in some cases). On Header
387	Type 01 bridges, the secondary status register is also looked at to see
388	if parity occurred on the bus on the other side of the bridge.
389	
390	
391	SYSFS CONFIGURATION
392	-------------------
393	
394	Under /sys/devices/system/edac/pci are control and attribute files as follows:
395	
396	
397	Enable/Disable PCI Parity checking control file:
398	
399		'check_pci_parity'
400	
401	
402		This control file enables or disables the PCI Bus Parity scanning
403		operation. Writing a 1 to this file enables the scanning. Writing
404		a 0 to this file disables the scanning.
405	
406		Enable:
407		echo "1" >/sys/devices/system/edac/pci/check_pci_parity
408	
409		Disable:
410		echo "0" >/sys/devices/system/edac/pci/check_pci_parity
411	
412	
413	Parity Count:
414	
415		'pci_parity_count'
416	
417		This attribute file will display the number of parity errors that
418		have been detected.
419	
420	
421	
422	MODULE PARAMETERS
423	-----------------
424	
425	Panic on UE control file:
426	
427		'edac_mc_panic_on_ue'
428	
429		An uncorrectable error will cause a machine panic.  This is usually
430		desirable.  It is a bad idea to continue when an uncorrectable error
431		occurs - it is indeterminate what was uncorrected and the operating
432		system context might be so mangled that continuing will lead to further
433		corruption. If the kernel has MCE configured, then EDAC will never
434		notice the UE.
435	
436		LOAD TIME: module/kernel parameter: edac_mc_panic_on_ue=[0|1]
437	
438		RUN TIME:  echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
439	
440	
441	Log UE control file:
442	
443		'edac_mc_log_ue'
444	
445		Generate kernel messages describing uncorrectable errors.  These errors
446		are reported through the system message log system.  UE statistics
447		will be accumulated even when UE logging is disabled.
448	
449		LOAD TIME: module/kernel parameter: edac_mc_log_ue=[0|1]
450	
451		RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
452	
453	
454	Log CE control file:
455	
456		'edac_mc_log_ce'
457	
458		Generate kernel messages describing correctable errors.  These
459		errors are reported through the system message log system.
460		CE statistics will be accumulated even when CE logging is disabled.
461	
462		LOAD TIME: module/kernel parameter: edac_mc_log_ce=[0|1]
463	
464		RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
465	
466	
467	Polling period control file:
468	
469		'edac_mc_poll_msec'
470	
471		The time period, in milliseconds, for polling for error information.
472		Too small a value wastes resources.  Too large a value might delay
473		necessary handling of errors and might loose valuable information for
474		locating the error.  1000 milliseconds (once each second) is the current
475		default. Systems which require all the bandwidth they can get, may
476		increase this.
477	
478		LOAD TIME: module/kernel parameter: edac_mc_poll_msec=[0|1]
479	
480		RUN TIME: echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
481	
482	
483	Panic on PCI PARITY Error:
484	
485		'panic_on_pci_parity'
486	
487	
488		This control file enables or disables panicking when a parity
489		error has been detected.
490	
491	
492		module/kernel parameter: edac_panic_on_pci_pe=[0|1]
493	
494		Enable:
495		echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
496	
497		Disable:
498		echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
499	
500	
501	
502	EDAC device type
503	----------------
504	
505	In the header file, edac_core.h, there is a series of edac_device structures
506	and APIs for the EDAC_DEVICE.
507	
508	User space access to an edac_device is through the sysfs interface.
509	
510	At the location /sys/devices/system/edac (sysfs) new edac_device devices will
511	appear.
512	
513	There is a three level tree beneath the above 'edac' directory. For example,
514	the 'test_device_edac' device (found at the bluesmoke.sourceforget.net website)
515	installs itself as:
516	
517		/sys/devices/systm/edac/test-instance
518	
519	in this directory are various controls, a symlink and one or more 'instance'
520	directories.
521	
522	The standard default controls are:
523	
524		log_ce		boolean to log CE events
525		log_ue		boolean to log UE events
526		panic_on_ue	boolean to 'panic' the system if an UE is encountered
527				(default off, can be set true via startup script)
528		poll_msec	time period between POLL cycles for events
529	
530	The test_device_edac device adds at least one of its own custom control:
531	
532		test_bits	which in the current test driver does nothing but
533				show how it is installed. A ported driver can
534				add one or more such controls and/or attributes
535				for specific uses.
536				One out-of-tree driver uses controls here to allow
537				for ERROR INJECTION operations to hardware
538				injection registers
539	
540	The symlink points to the 'struct dev' that is registered for this edac_device.
541	
542	INSTANCES
543	---------
544	
545	One or more instance directories are present. For the 'test_device_edac' case:
546	
547		test-instance0
548	
549	
550	In this directory there are two default counter attributes, which are totals of
551	counter in deeper subdirectories.
552	
553		ce_count	total of CE events of subdirectories
554		ue_count	total of UE events of subdirectories
555	
556	BLOCKS
557	------
558	
559	At the lowest directory level is the 'block' directory. There can be 0, 1
560	or more blocks specified in each instance.
561	
562		test-block0
563	
564	
565	In this directory the default attributes are:
566	
567		ce_count	which is counter of CE events for this 'block'
568				of hardware being monitored
569		ue_count	which is counter of UE events for this 'block'
570				of hardware being monitored
571	
572	
573	The 'test_device_edac' device adds 4 attributes and 1 control:
574	
575		test-block-bits-0	for every POLL cycle this counter
576					is incremented
577		test-block-bits-1	every 10 cycles, this counter is bumped once,
578					and test-block-bits-0 is set to 0
579		test-block-bits-2	every 100 cycles, this counter is bumped once,
580					and test-block-bits-1 is set to 0
581		test-block-bits-3	every 1000 cycles, this counter is bumped once,
582					and test-block-bits-2 is set to 0
583	
584	
585		reset-counters		writing ANY thing to this control will
586					reset all the above counters.
587	
588	
589	Use of the 'test_device_edac' driver should enable any others to create their own
590	unique drivers for their hardware systems.
591	
592	The 'test_device_edac' sample driver is located at the
593	bluesmoke.sourceforge.net project site for EDAC.
594	
595	
596	NEHALEM USAGE OF EDAC APIs
597	--------------------------
598	
599	This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
600	Nehalem EDAC driver. They will likely be changed on future versions
601	of the driver.
602	
603	Due to the way Nehalem exports Memory Controller data, some adjustments
604	were done at i7core_edac driver. This chapter will cover those differences
605	
606	1) On Nehalem, there is one Memory Controller per Quick Patch Interconnect
607	   (QPI). At the driver, the term "socket" means one QPI. This is
608	   associated with a physical CPU socket.
609	
610	   Each MC have 3 physical read channels, 3 physical write channels and
611	   3 logic channels. The driver currently sees it as just 3 channels.
612	   Each channel can have up to 3 DIMMs.
613	
614	   The minimum known unity is DIMMs. There are no information about csrows.
615	   As EDAC API maps the minimum unity is csrows, the driver sequentially
616	   maps channel/dimm into different csrows.
617	
618	   For example, supposing the following layout:
619		Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
620		  dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
621		  dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
622	        Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
623		  dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
624		Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
625		  dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
626	   The driver will map it as:
627		csrow0: channel 0, dimm0
628		csrow1: channel 0, dimm1
629		csrow2: channel 1, dimm0
630		csrow3: channel 2, dimm0
631	
632	exports one
633	   DIMM per csrow.
634	
635	   Each QPI is exported as a different memory controller.
636	
637	2) Nehalem MC has the ability to generate errors. The driver implements this
638	   functionality via some error injection nodes:
639	
640	   For injecting a memory error, there are some sysfs nodes, under
641	   /sys/devices/system/edac/mc/mc?/:
642	
643	   inject_addrmatch/*:
644	      Controls the error injection mask register. It is possible to specify
645	      several characteristics of the address to match an error code:
646	         dimm = the affected dimm. Numbers are relative to a channel;
647	         rank = the memory rank;
648	         channel = the channel that will generate an error;
649	         bank = the affected bank;
650	         page = the page address;
651	         column (or col) = the address column.
652	      each of the above values can be set to "any" to match any valid value.
653	
654	      At driver init, all values are set to any.
655	
656	      For example, to generate an error at rank 1 of dimm 2, for any channel,
657	      any bank, any page, any column:
658			echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
659			echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
660	
661		To return to the default behaviour of matching any, you can do:
662			echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
663			echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
664	
665	   inject_eccmask:
666	       specifies what bits will have troubles,
667	
668	   inject_section:
669	       specifies what ECC cache section will get the error:
670			3 for both
671			2 for the highest
672			1 for the lowest
673	
674	   inject_type:
675	       specifies the type of error, being a combination of the following bits:
676			bit 0 - repeat
677			bit 1 - ecc
678			bit 2 - parity
679	
680	       inject_enable starts the error generation when something different
681	       than 0 is written.
682	
683	   All inject vars can be read. root permission is needed for write.
684	
685	   Datasheet states that the error will only be generated after a write on an
686	   address that matches inject_addrmatch. It seems, however, that reading will
687	   also produce an error.
688	
689	   For example, the following code will generate an error for any write access
690	   at socket 0, on any DIMM/address on channel 2:
691	
692	   echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
693	   echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
694	   echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
695	   echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
696	   echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
697	   dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
698	
699	   For socket 1, it is needed to replace "mc0" by "mc1" at the above
700	   commands.
701	
702	   The generated error message will look like:
703	
704	   EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
705	
706	3) Nehalem specific Corrected Error memory counters
707	
708	   Nehalem have some registers to count memory errors. The driver uses those
709	   registers to report Corrected Errors on devices with Registered Dimms.
710	
711	   However, those counters don't work with Unregistered Dimms. As the chipset
712	   offers some counters that also work with UDIMMS (but with a worse level of
713	   granularity than the default ones), the driver exposes those registers for
714	   UDIMM memories.
715	
716	   They can be read by looking at the contents of all_channel_counts/
717	
718	   $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
719		/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
720		0
721		/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
722		0
723		/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
724		0
725	
726	   What happens here is that errors on different csrows, but at the same
727	   dimm number will increment the same counter.
728	   So, in this memory mapping:
729		csrow0: channel 0, dimm0
730		csrow1: channel 0, dimm1
731		csrow2: channel 1, dimm0
732		csrow3: channel 2, dimm0
733	   The hardware will increment udimm0 for an error at the first dimm at either
734		csrow0, csrow2  or csrow3;
735	   The hardware will increment udimm1 for an error at the second dimm at either
736		csrow0, csrow2  or csrow3;
737	   The hardware will increment udimm2 for an error at the third dimm at either
738		csrow0, csrow2  or csrow3;
739	
740	4) Standard error counters
741	
742	   The standard error counters are generated when an mcelog error is received
743	   by the driver. Since, with udimm, this is counted by software, it is
744	   possible that some errors could be lost. With rdimm's, they display the
745	   contents of the registers
746	
747	CREDITS:
748	========
749	
750	Written by Doug Thompson <dougthompson@xmission.com>
751	7 Dec 2005
752	17 Jul 2007	Updated
753	
754	(c) Mauro Carvalho Chehab
755	05 Aug 2009	Nehalem interface
756	
757	EDAC authors/maintainers:
758	
759		Doug Thompson, Dave Jiang, Dave Peterson et al,
760		Mauro Carvalho Chehab
761		Borislav Petkov
762		original author: Thayne Harbaugh
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.