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