ramoops ECC: What Error Correction Can Recover After a Warm Reset

A damaged ramoops record creates two different questions: did the reset preserve the RAM, and can software repair the bytes that remain? Enabling ECC answers only part of the second question. This guide uses upstream Linux v6.12 to decide when ramoops error correction is useful, how to inspect its effective configuration, and what evidence a recovery claim needs. The workflow below is a proposed engineering procedure; no board-level reset or fault-injection results are claimed.

Start with a specific corruption hypothesis

Describe the observed damage before changing settings. Is the entire previous record absent, is a readable record interrupted by corrupted characters, or does the recovery kernel report an invalid buffer header? Record the reset cause, firmware versions, kernel build identity, and whether the same record was collected more than once. These observations lead to different experiments. An empty region following firmware initialization does not establish an error-correction defect.

Ramoops depends on memory surviving a restart; its documented software ECC feature addresses some corruption in retained memory. It cannot recreate a log that was never written or convert ordinary RAM into nonvolatile storage. Treat power removal, firmware clearing, and incomplete writes as separate failure mechanisms. Linux 6.12 ramoops documentation.

Understand the protected objects

The v6.12 persistent-RAM implementation protects data blocks and maintains separate parity for the buffer header. Its default block size is 128 bytes when a caller does not specify one. Recovery attempts produce corrected-byte and unrecoverable-block counters. These are decoder observations, not proof that the entire incident is reconstructed. v6.12 persistent-RAM implementation.

Keep three outcomes distinct in an investigation report: data was available without detected errors; correction was reported and the recovered content matched an independent reference; or some content remained untrustworthy. A readable stack trace alone belongs to none of those acceptance categories until the expected markers and incident identity have been checked. ECC also provides no authenticity guarantee against deliberate changes.

Verify the effective configuration, not a remembered flag

Inspect the exact build configuration for CONFIG_PSTORE and CONFIG_PSTORE_RAM. In v6.12, PSTORE_RAM selects the Reed–Solomon encoder and decoder support. Having those options built does not itself enable ECC for a particular region. v6.12 pstore Kconfig.

# Read-only checks on the running target
uname -r
cat /proc/cmdline
cat /sys/module/ramoops/parameters/ecc
dmesg | grep -Ei 'ramoops|persistent_ram|ECC'

The ecc sysfs entry is a module-parameter view; the v6.12 driver does not synchronize it from device-tree ECC settings. For a device-tree deployment, rely on the deployed ecc-size and startup evidence rather than treating a zero there as proof that ECC is off. Some paths or messages may be unavailable under the product’s configuration or permissions. Obtain the release’s saved kernel configuration and deployed device tree through the normal build artifacts when necessary. Do not interpret a missing sysfs file as a complete diagnosis.

The module-parameter path gives ramoops.ecc=1 a compatibility meaning of 16 ECC bytes. The device-tree property ecc-size specifies a byte count; use an explicit value such as 16 in the approved device tree rather than transferring that shorthand. The driver startup message and deployed configuration should agree. v6.12 ramoops driver and ramoops binding.

Account for parity without promising extra retention

ECC consumes space that otherwise could hold retained content. For a planning example, 128 data bytes with 16 parity bytes produce a 144-byte block envelope: parity is 12.5% of the data amount, or about 11.1% of that envelope. Header protection and rounding add further overhead. This arithmetic is an illustrative model, not an exact usable-record calculation for a configured zone.

Compare a representative uncorrupted record before and after an ECC configuration change. Confirm that the fields needed to identify the failure still fit. If the record now loses an important precursor, choose explicitly between greater correction redundancy and the lost diagnostic context. Do not report a larger ECC number as universally better. The supported geometry, write path, and desired evidence must remain compatible.

Design isolated corruption experiments

Begin with an offline or instrumented test harness that owns a disposable buffer and uses the selected kernel’s layout and decoder. Create a known message with numbered lines and a stored reference hash. Exercise unchanged data, altered data bytes, altered parity, a damaged header, and damage concentrated within one block versus spread across blocks. Label every case synthetic.

For each case, retain the input bytes, fault coordinates, recovery output, decoder status, and an independent byte comparison. A decoder reporting correction is useful evidence only when the expected content also matches. Uncorrectable patterns must remain visibly failed; do not silently include them in a successful-recovery rate. Reed–Solomon operates on symbols, so counting flipped bits alone is an inadequate test specification. Linux v6.12 Reed–Solomon decoder.

Only then plan a warm-reset experiment on an isolated development board with a recovery path and explicit permission to lose its current workload. Avoid ad hoc writes through physical-memory devices on a running production system. A software decoder test validates the correction path; a reset experiment additionally investigates that board’s actual retention behavior. Neither substitutes for the other.

Use a narrow acceptance statement

• The exact kernel, firmware, device tree, ECC geometry, and reset mechanism are recorded.
• The unmodified reference is recovered, with incident markers intact.
• Each supported injected corruption pattern has byte-level evidence, including reported corrections.
• Unrecoverable cases are recognized and excluded from complete-log claims.
• The operational procedure states what happens after power loss, clearing, overwrite, or interrupted capture.

The useful deliverable is a qualified statement such as “this configuration recovered these specified synthetic corruption cases under this tested reset path.” It is not “ECC guarantees persistent crash logs.” If a fleet failure falls outside the tested envelope, preserve the evidence and reopen the retention hypothesis before changing parity parameters.