]> git.proxmox.com Git - mirror_ubuntu-zesty-kernel.git/blob - Documentation/edac.txt
DocBook: use DOCBOOKS="" to ignore DocBooks instead of IGNORE_DOCBOOKS=1
[mirror_ubuntu-zesty-kernel.git] / Documentation / edac.txt
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