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
 237
 238Counter reset control file:
 239
 240        'reset_counters'
 241
 242        This write-only control file will zero all the statistical counters
 243        for UE and CE errors.  Zeroing the counters will also reset the timer
 244        indicating how long since the last counter zero.  This is useful
 245        for computing errors/time.  Since the counters are always reset at
 246        driver initialization time, no module/kernel parameter is available.
 247
 248        RUN TIME: echo "anything" >/sys/devices/system/edac/mc/mc0/counter_reset
 249
 250                This resets the counters on memory controller 0
 251
 252
 253Seconds since last counter reset control file:
 254
 255        'seconds_since_reset'
 256
 257        This attribute file displays how many seconds have elapsed since the
 258        last counter reset. This can be used with the error counters to
 259        measure error rates.
 260
 261
 262
 263Memory Controller name attribute file:
 264
 265        'mc_name'
 266
 267        This attribute file displays the type of memory controller
 268        that is being utilized.
 269
 270
 271Total memory managed by this memory controller attribute file:
 272
 273        'size_mb'
 274
 275        This attribute file displays, in count of megabytes, of memory
 276        that this instance of memory controller manages.
 277
 278
 279Total Uncorrectable Errors count attribute file:
 280
 281        'ue_count'
 282
 283        This attribute file displays the total count of uncorrectable
 284        errors that have occurred on this memory controller. If panic_on_ue
 285        is set this counter will not have a chance to increment,
 286        since EDAC will panic the system.
 287
 288
 289Total UE count that had no information attribute fileY:
 290
 291        'ue_noinfo_count'
 292
 293        This attribute file displays the number of UEs that have occurred
 294        with no information as to which DIMM slot is having errors.
 295
 296
 297Total Correctable Errors count attribute file:
 298
 299        'ce_count'
 300
 301        This attribute file displays the total count of correctable
 302        errors that have occurred on this memory controller. This
 303        count is very important to examine. CEs provide early
 304        indications that a DIMM is beginning to fail. This count
 305        field should be monitored for non-zero values and report
 306        such information to the system administrator.
 307
 308
 309Total Correctable Errors count attribute file:
 310
 311        'ce_noinfo_count'
 312
 313        This attribute file displays the number of CEs that
 314        have occurred wherewith no information as to which DIMM slot
 315        is having errors. Memory is handicapped, but operational,
 316        yet no information is available to indicate which slot
 317        the failing memory is in. This count field should be also
 318        be monitored for non-zero values.
 319
 320Device Symlink:
 321
 322        'device'
 323
 324        Symlink to the memory controller device.
 325
 326Sdram memory scrubbing rate:
 327
 328        'sdram_scrub_rate'
 329
 330        Read/Write attribute file that controls memory scrubbing. The scrubbing
 331        rate is set by writing a minimum bandwidth in bytes/sec to the attribute
 332        file. The rate will be translated to an internal value that gives at
 333        least the specified rate.
 334
 335        Reading the file will return the actual scrubbing rate employed.
 336
 337        If configuration fails or memory scrubbing is not implemented, accessing
 338        that attribute will fail.
 339
 340
 341
 342============================================================================
 343'csrowX' DIRECTORIES
 344
 345In the 'csrowX' directories are EDAC control and attribute files for
 346this 'X' instance of csrow:
 347
 348
 349Total Uncorrectable Errors count attribute file:
 350
 351        'ue_count'
 352
 353        This attribute file displays the total count of uncorrectable
 354        errors that have occurred on this csrow. If panic_on_ue is set
 355        this counter will not have a chance to increment, since EDAC
 356        will panic the system.
 357
 358
 359Total Correctable Errors count attribute file:
 360
 361        'ce_count'
 362
 363        This attribute file displays the total count of correctable
 364        errors that have occurred on this csrow. This
 365        count is very important to examine. CEs provide early
 366        indications that a DIMM is beginning to fail. This count
 367        field should be monitored for non-zero values and report
 368        such information to the system administrator.
 369
 370
 371Total memory managed by this csrow attribute file:
 372
 373        'size_mb'
 374
 375        This attribute file displays, in count of megabytes, of memory
 376        that this csrow contains.
 377
 378
 379Memory Type attribute file:
 380
 381        'mem_type'
 382
 383        This attribute file will display what type of memory is currently
 384        on this csrow. Normally, either buffered or unbuffered memory.
 385        Examples:
 386                Registered-DDR
 387                Unbuffered-DDR
 388
 389
 390EDAC Mode of operation attribute file:
 391
 392        'edac_mode'
 393
 394        This attribute file will display what type of Error detection
 395        and correction is being utilized.
 396
 397
 398Device type attribute file:
 399
 400        'dev_type'
 401
 402        This attribute file will display what type of DRAM device is
 403        being utilized on this DIMM.
 404        Examples:
 405                x1
 406                x2
 407                x4
 408                x8
 409
 410
 411Channel 0 CE Count attribute file:
 412
 413        'ch0_ce_count'
 414
 415        This attribute file will display the count of CEs on this
 416        DIMM located in channel 0.
 417
 418
 419Channel 0 UE Count attribute file:
 420
 421        'ch0_ue_count'
 422
 423        This attribute file will display the count of UEs on this
 424        DIMM located in channel 0.
 425
 426
 427Channel 0 DIMM Label control file:
 428
 429        'ch0_dimm_label'
 430
 431        This control file allows this DIMM to have a label assigned
 432        to it. With this label in the module, when errors occur
 433        the output can provide the DIMM label in the system log.
 434        This becomes vital for panic events to isolate the
 435        cause of the UE event.
 436
 437        DIMM Labels must be assigned after booting, with information
 438        that correctly identifies the physical slot with its
 439        silk screen label. This information is currently very
 440        motherboard specific and determination of this information
 441        must occur in userland at this time.
 442
 443
 444Channel 1 CE Count attribute file:
 445
 446        'ch1_ce_count'
 447
 448        This attribute file will display the count of CEs on this
 449        DIMM located in channel 1.
 450
 451
 452Channel 1 UE Count attribute file:
 453
 454        'ch1_ue_count'
 455
 456        This attribute file will display the count of UEs on this
 457        DIMM located in channel 0.
 458
 459
 460Channel 1 DIMM Label control file:
 461
 462        'ch1_dimm_label'
 463
 464        This control file allows this DIMM to have a label assigned
 465        to it. With this label in the module, when errors occur
 466        the output can provide the DIMM label in the system log.
 467        This becomes vital for panic events to isolate the
 468        cause of the UE event.
 469
 470        DIMM Labels must be assigned after booting, with information
 471        that correctly identifies the physical slot with its
 472        silk screen label. This information is currently very
 473        motherboard specific and determination of this information
 474        must occur in userland at this time.
 475
 476============================================================================
 477SYSTEM LOGGING
 478
 479If logging for UEs and CEs are enabled then system logs will have
 480error notices indicating errors that have been detected:
 481
 482EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0,
 483channel 1 "DIMM_B1": amd76x_edac
 484
 485EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0,
 486channel 1 "DIMM_B1": amd76x_edac
 487
 488
 489The structure of the message is:
 490        the memory controller                   (MC0)
 491        Error type                              (CE)
 492        memory page                             (0x283)
 493        offset in the page                      (0xce0)
 494        the byte granularity                    (grain 8)
 495                or resolution of the error
 496        the error syndrome                      (0xb741)
 497        memory row                              (row 0)
 498        memory channel                          (channel 1)
 499        DIMM label, if set prior                (DIMM B1
 500        and then an optional, driver-specific message that may
 501                have additional information.
 502
 503Both UEs and CEs with no info will lack all but memory controller,
 504error type, a notice of "no info" and then an optional,
 505driver-specific error message.
 506
 507
 508============================================================================
 509PCI Bus Parity Detection
 510
 511
 512On Header Type 00 devices the primary status is looked at
 513for any parity error regardless of whether Parity is enabled on the
 514device.  (The spec indicates parity is generated in some cases).
 515On Header Type 01 bridges, the secondary status register is also
 516looked at to see if parity occurred on the bus on the other side of
 517the bridge.
 518
 519
 520SYSFS CONFIGURATION
 521
 522Under /sys/devices/system/edac/pci are control and attribute files as follows:
 523
 524
 525Enable/Disable PCI Parity checking control file:
 526
 527        'check_pci_parity'
 528
 529
 530        This control file enables or disables the PCI Bus Parity scanning
 531        operation. Writing a 1 to this file enables the scanning. Writing
 532        a 0 to this file disables the scanning.
 533
 534        Enable:
 535        echo "1" >/sys/devices/system/edac/pci/check_pci_parity
 536
 537        Disable:
 538        echo "0" >/sys/devices/system/edac/pci/check_pci_parity
 539
 540
 541Parity Count:
 542
 543        'pci_parity_count'
 544
 545        This attribute file will display the number of parity errors that
 546        have been detected.
 547
 548
 549============================================================================
 550MODULE PARAMETERS
 551
 552Panic on UE control file:
 553
 554        'edac_mc_panic_on_ue'
 555
 556        An uncorrectable error will cause a machine panic.  This is usually
 557        desirable.  It is a bad idea to continue when an uncorrectable error
 558        occurs - it is indeterminate what was uncorrected and the operating
 559        system context might be so mangled that continuing will lead to further
 560        corruption. If the kernel has MCE configured, then EDAC will never
 561        notice the UE.
 562
 563        LOAD TIME: module/kernel parameter: edac_mc_panic_on_ue=[0|1]
 564
 565        RUN TIME:  echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
 566
 567
 568Log UE control file:
 569
 570        'edac_mc_log_ue'
 571
 572        Generate kernel messages describing uncorrectable errors.  These errors
 573        are reported through the system message log system.  UE statistics
 574        will be accumulated even when UE logging is disabled.
 575
 576        LOAD TIME: module/kernel parameter: edac_mc_log_ue=[0|1]
 577
 578        RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
 579
 580
 581Log CE control file:
 582
 583        'edac_mc_log_ce'
 584
 585        Generate kernel messages describing correctable errors.  These
 586        errors are reported through the system message log system.
 587        CE statistics will be accumulated even when CE logging is disabled.
 588
 589        LOAD TIME: module/kernel parameter: edac_mc_log_ce=[0|1]
 590
 591        RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
 592
 593
 594Polling period control file:
 595
 596        'edac_mc_poll_msec'
 597
 598        The time period, in milliseconds, for polling for error information.
 599        Too small a value wastes resources.  Too large a value might delay
 600        necessary handling of errors and might loose valuable information for
 601        locating the error.  1000 milliseconds (once each second) is the current
 602        default. Systems which require all the bandwidth they can get, may
 603        increase this.
 604
 605        LOAD TIME: module/kernel parameter: edac_mc_poll_msec=[0|1]
 606
 607        RUN TIME: echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
 608
 609
 610Panic on PCI PARITY Error:
 611
 612        'panic_on_pci_parity'
 613
 614
 615        This control files enables or disables panicking when a parity
 616        error has been detected.
 617
 618
 619        module/kernel parameter: edac_panic_on_pci_pe=[0|1]
 620
 621        Enable:
 622        echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
 623
 624        Disable:
 625        echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
 626
 627
 628
 629=======================================================================
 630
 631
 632EDAC_DEVICE type of device
 633
 634In the header file, edac_core.h, there is a series of edac_device structures
 635and APIs for the EDAC_DEVICE.
 636
 637User space access to an edac_device is through the sysfs interface.
 638
 639At the location /sys/devices/system/edac (sysfs) new edac_device devices will
 640appear.
 641
 642There is a three level tree beneath the above 'edac' directory. For example,
 643the 'test_device_edac' device (found at the bluesmoke.sourceforget.net website)
 644installs itself as:
 645
 646        /sys/devices/systm/edac/test-instance
 647
 648in this directory are various controls, a symlink and one or more 'instance'
 649directorys.
 650
 651The standard default controls are:
 652
 653        log_ce          boolean to log CE events
 654        log_ue          boolean to log UE events
 655        panic_on_ue     boolean to 'panic' the system if an UE is encountered
 656                        (default off, can be set true via startup script)
 657        poll_msec       time period between POLL cycles for events
 658
 659The test_device_edac device adds at least one of its own custom control:
 660
 661        test_bits       which in the current test driver does nothing but
 662                        show how it is installed. A ported driver can
 663                        add one or more such controls and/or attributes
 664                        for specific uses.
 665                        One out-of-tree driver uses controls here to allow
 666                        for ERROR INJECTION operations to hardware
 667                        injection registers
 668
 669The symlink points to the 'struct dev' that is registered for this edac_device.
 670
 671INSTANCES
 672
 673One or more instance directories are present. For the 'test_device_edac' case:
 674
 675        test-instance0
 676
 677
 678In this directory there are two default counter attributes, which are totals of
 679counter in deeper subdirectories.
 680
 681        ce_count        total of CE events of subdirectories
 682        ue_count        total of UE events of subdirectories
 683
 684BLOCKS
 685
 686At the lowest directory level is the 'block' directory. There can be 0, 1
 687or more blocks specified in each instance.
 688
 689        test-block0
 690
 691
 692In this directory the default attributes are:
 693
 694        ce_count        which is counter of CE events for this 'block'
 695                        of hardware being monitored
 696        ue_count        which is counter of UE events for this 'block'
 697                        of hardware being monitored
 698
 699
 700The 'test_device_edac' device adds 4 attributes and 1 control:
 701
 702        test-block-bits-0       for every POLL cycle this counter
 703                                is incremented
 704        test-block-bits-1       every 10 cycles, this counter is bumped once,
 705                                and test-block-bits-0 is set to 0
 706        test-block-bits-2       every 100 cycles, this counter is bumped once,
 707                                and test-block-bits-1 is set to 0
 708        test-block-bits-3       every 1000 cycles, this counter is bumped once,
 709                                and test-block-bits-2 is set to 0
 710
 711
 712        reset-counters          writing ANY thing to this control will
 713                                reset all the above counters.
 714
 715
 716Use of the 'test_device_edac' driver should any others to create their own
 717unique drivers for their hardware systems.
 718
 719The 'test_device_edac' sample driver is located at the
 720bluesmoke.sourceforge.net project site for EDAC.
 721
 722=======================================================================
 723NEHALEM USAGE OF EDAC APIs
 724
 725This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
 726Nehalem EDAC driver. They will likely be changed on future versions
 727of the driver.
 728
 729Due to the way Nehalem exports Memory Controller data, some adjustments
 730were done at i7core_edac driver. This chapter will cover those differences
 731
 7321) On Nehalem, there are one Memory Controller per Quick Patch Interconnect
 733   (QPI). At the driver, the term "socket" means one QPI. This is
 734   associated with a physical CPU socket.
 735
 736   Each MC have 3 physical read channels, 3 physical write channels and
 737   3 logic channels. The driver currently sees it as just 3 channels.
 738   Each channel can have up to 3 DIMMs.
 739
 740   The minimum known unity is DIMMs. There are no information about csrows.
 741   As EDAC API maps the minimum unity is csrows, the driver sequencially
 742   maps channel/dimm into different csrows.
 743
 744   For example, supposing the following layout:
 745        Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
 746          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
 747          dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
 748        Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
 749          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
 750        Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
 751          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
 752   The driver will map it as:
 753        csrow0: channel 0, dimm0
 754        csrow1: channel 0, dimm1
 755        csrow2: channel 1, dimm0
 756        csrow3: channel 2, dimm0
 757
 758exports one
 759   DIMM per csrow.
 760
 761   Each QPI is exported as a different memory controller.
 762
 7632) Nehalem MC has the hability to generate errors. The driver implements this
 764   functionality via some error injection nodes:
 765
 766   For injecting a memory error, there are some sysfs nodes, under
 767   /sys/devices/system/edac/mc/mc?/:
 768
 769   inject_addrmatch/*:
 770      Controls the error injection mask register. It is possible to specify
 771      several characteristics of the address to match an error code:
 772         dimm = the affected dimm. Numbers are relative to a channel;
 773         rank = the memory rank;
 774         channel = the channel that will generate an error;
 775         bank = the affected bank;
 776         page = the page address;
 777         column (or col) = the address column.
 778      each of the above values can be set to "any" to match any valid value.
 779
 780      At driver init, all values are set to any.
 781
 782      For example, to generate an error at rank 1 of dimm 2, for any channel,
 783      any bank, any page, any column:
 784                echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
 785                echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
 786
 787        To return to the default behaviour of matching any, you can do:
 788                echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
 789                echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
 790
 791   inject_eccmask:
 792       specifies what bits will have troubles,
 793
 794   inject_section:
 795       specifies what ECC cache section will get the error:
 796                3 for both
 797                2 for the highest
 798                1 for the lowest
 799
 800   inject_type:
 801       specifies the type of error, being a combination of the following bits:
 802                bit 0 - repeat
 803                bit 1 - ecc
 804                bit 2 - parity
 805
 806       inject_enable starts the error generation when something different
 807       than 0 is written.
 808
 809   All inject vars can be read. root permission is needed for write.
 810
 811   Datasheet states that the error will only be generated after a write on an
 812   address that matches inject_addrmatch. It seems, however, that reading will
 813   also produce an error.
 814
 815   For example, the following code will generate an error for any write access
 816   at socket 0, on any DIMM/address on channel 2:
 817
 818   echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
 819   echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
 820   echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
 821   echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
 822   echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
 823   dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
 824
 825   For socket 1, it is needed to replace "mc0" by "mc1" at the above
 826   commands.
 827
 828   The generated error message will look like:
 829
 830   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))
 831
 8323) Nehalem specific Corrected Error memory counters
 833
 834   Nehalem have some registers to count memory errors. The driver uses those
 835   registers to report Corrected Errors on devices with Registered Dimms.
 836
 837   However, those counters don't work with Unregistered Dimms. As the chipset
 838   offers some counters that also work with UDIMMS (but with a worse level of
 839   granularity than the default ones), the driver exposes those registers for
 840   UDIMM memories.
 841
 842   They can be read by looking at the contents of all_channel_counts/
 843
 844   $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
 845        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
 846        0
 847        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
 848        0
 849        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
 850        0
 851
 852   What happens here is that errors on different csrows, but at the same
 853   dimm number will increment the same counter.
 854   So, in this memory mapping:
 855        csrow0: channel 0, dimm0
 856        csrow1: channel 0, dimm1
 857        csrow2: channel 1, dimm0
 858        csrow3: channel 2, dimm0
 859   The hardware will increment udimm0 for an error at the first dimm at either
 860        csrow0, csrow2  or csrow3;
 861   The hardware will increment udimm1 for an error at the second dimm at either
 862        csrow0, csrow2  or csrow3;
 863   The hardware will increment udimm2 for an error at the third dimm at either
 864        csrow0, csrow2  or csrow3;
 865
 8664) Standard error counters
 867
 868   The standard error counters are generated when an mcelog error is received
 869   by the driver. Since, with udimm, this is counted by software, it is
 870   possible that some errors could be lost. With rdimm's, they displays the
 871   contents of the registers
 872
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.