EDAC Error Reports: Separate Corrected Memory Events from an Application Buffer Bug

Read an EDAC event as a hardware-reporting record with a severity, topology and observation boundary. Preserve the raw event and the controller’s available counters before deciding whether it points to one replaceable component, a broader platform problem or an unrelated application defect.

The reference is upstream Linux v6.12’s EDAC subsystem and documented sysfs ABI. The actual controller driver, firmware and memory topology determine which fields exist and how precisely an event can be located. No memory-error injection, device test or remaining-life estimate is claimed here.

Establish which hardware is monitored

The EDAC documentation distinguishes memory controllers, channels, ranks, sockets and other monitored devices. These names are not interchangeable. A controller’s logical channel identifier does not automatically identify a silkscreened socket or a soldered DRAM package.

Record the bound EDAC driver, controller identity, kernel and firmware versions, memory configuration and successful registration evidence. Identify what the platform actually reports: memory-controller events, another EDAC device type, or a different hardware-error route. An absent EDAC directory cannot prove that memory is error-free.

Keep error-reporting capability separate from correction capability. A product description mentioning ECC does not establish that Linux receives all relevant events or that every field is decoded by the selected driver. Verify the actual firmware and controller operating mode against platform documentation.

Capture severity without flattening it

Retain whether the event is reported as corrected, uncorrected, deferred, fatal or another supported class. The subsystem’s definitions distinguish these outcomes. Do not merge them into one “memory errors” count if the operational response depends on whether data could be corrected or the system recovered.

A corrected event says the reporting mechanism corrected the reported error. It does not certify every byte used by the application, predict the next event or prove that a module will remain reliable for a particular duration. An uncorrected event likewise needs its actual handling and affected context; it is not automatically interchangeable with an immediate fatal reset.

Preserve available address, syndrome, grain or location details as reported. Mark absent or unknown fields explicitly. Never convert an unknown location into a precise DIMM label because the inventory contains only one convenient candidate.

Inventory the read-only sysfs evidence

The v6.12 EDAC sysfs ABI describes controller fields such as mc_name, ce_count, ue_count, no-information counters and seconds_since_reset. Per-DIMM or per-rank directories can expose size, location, label, mode and their own counts. Read only attributes actually present.

Counter age is not necessarily system uptime. The ABI states that initialization resets counters, and the reset control resets both statistics and their time origin. The tagged implementation performs that reset. Preserve the current baseline before any maintenance action that could remove history.

Do not clear counters to make a graph look clean. For ordinary investigation, take timestamped snapshots and calculate deltas across a known uninterrupted counter epoch. If the counter decreases or its age restarts, treat the interval as discontinuous rather than computing a negative error rate.

Build a topology and event ledger

Ledger field	Required distinction
Controller and driver	Which reporting path produced the event?
Logical location	Channel/rank/slot fields versus unknown or aggregate location
Physical mapping	Verified board/vendor label versus an inferred socket name
Severity and count	Reported class, raw event and counter epoch
Exposure	Elapsed observation, workload and relevant operating conditions

Some configurations span multiple modules for one access or correction unit. The EDAC reference specifically cautions that topology can prevent locating an event to one memory stick. Report the smallest location actually supported by the evidence, even when that is an entire channel or group.

DIMM labels can be assigned by userspace and require board-specific mapping. Treat a label as trustworthy only after its physical association is verified. A mislabeled slot can turn good diagnostic data into replacement of the wrong part.

Separate hardware events from software buffer corruption

A software writer can store the wrong logical value while producing an ordinary valid memory write. Hardware correction does not know that the application intended different data. Therefore a kernel buffer overrun need not produce an EDAC event, and zero corrected-error counters do not exclude a software memory bug.

Conversely, a real corrected hardware event deserves preservation even if an application test passes. Correlate timing, address/location information and affected workload, while keeping causation unproven until the data connects them. Do not dismiss repeated hardware reports merely because a separate sanitizer found a software defect.

Choose an escalation from recurrence and consequence

1. Preserve the first raw event and current topology/counter snapshot.
2. Establish whether similar events recur at the same reported location and within the same counter epoch.
3. Compare workload and operating conditions without inventing an unmeasured thermal or voltage explanation.
4. Apply the platform vendor’s service and containment criteria, especially for uncorrected or fatal events.
5. Retain any data-integrity concern and recovery failure as an unresolved operational issue until reviewed.

There is no universal corrected-error count that this article can turn into a replacement deadline. Different reporting granularity, scrubbing policies, memory organizations and service requirements change the meaning of recurrence. Use explicit product and vendor criteria rather than predicting remaining memory life from a short count series.

Qualify changes without destroying the original evidence

For a hypothetical board reporting repeated corrected events on one logical channel, verify the physical mapping before a controlled replacement or reconfiguration experiment. Keep the original component identity, firmware and memory settings. Change one approved variable and compare a documented workload and observation window.

A quiet post-change interval supports only the tested conditions. It cannot prove the previous component was the sole cause or that the new configuration will never report another event. Deliberate hardware-error injection requires a separate platform-supported, isolated plan; arbitrary memory writes are not an ECC qualification method.

Deliver the topology map, raw events, counter epochs, recurrence record and escalation decision. The useful outcome is a defensible hardware investigation boundary, with software corruption and unreported failure modes still treated separately.