About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / edac.txt




Custom Search

Based on kernel version 4.7.2. Page generated on 2016-08-22 22:45 EST.

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