AXON V0.2 - BYTE-LEVEL DRAM CORRUPTION ON TWO BOARDS
Evidence bundle accompanying the forum report. 2026-09-17.

Two AXON V0.2 boards, 8 GiB LPDDR4X, no ECC, kernel 6.1.75-axon-fleet4.
Boards are anonymised as "Board A" and "Board B" throughout. Serial numbers,
MACs, IPs, hostnames and account names have been removed deliberately - we can
supply SoC / eMMC / NVMe serials privately if they help a batch check or an RMA.

Everything below is generated by script from the raw logs on the boards. The
generator scripts and the tooling sources are included so you can reproduce the
analysis rather than trust it.

----------------------------------------------------------------------
BOARD A  -  page-cache corruption detector, 2026-09-08 fault epoch
----------------------------------------------------------------------
01-analysis-summary.txt        START HERE. 150 frames, 172 events, 2,045 bad
                               bytes, clustering, bit polarity, byte offsets.
02-frames-150.txt              every faulting physical frame, with event counts
03-pagecheck-extract.log       the detector's own raw output for those events
04-pagecache-control.txt       THE CONTROL. Where the page cache actually landed
                               (measured, 1 GiB mapped) vs where the faults are.
                               This is what turns "clustered" into a number.
05-dram-frequency-controller.txt   the dmc/DVFS investigation - including the
                               claim we RETRACTED and why
06-ecc-and-edac.txt            kernel config, EDAC state, why nothing reports

----------------------------------------------------------------------
BOARD B  -  resident mlocked canary, still faulting now
----------------------------------------------------------------------
10-captures-analysis.txt       17 fully-instrumented captures: bit structure,
                               transience proof, byte-lane analysis
11-captures-raw.jsonl          the raw capture records. Every number in file 10
                               is derived from this; nothing was retyped.
12-soak-and-coverage.txt       1,275 passes, 96.091% cumulative coverage, and
                               why the wide sweep and the canary do not disagree
13-build-artefact-corruption.txt   the original symptom: one flipped byte in a
                               13.7 MB binary that reached disk

----------------------------------------------------------------------
TOOLING  -  so you can reproduce this
----------------------------------------------------------------------
tools/pagecheck.rs             Board A detector. Compares page-cache reads
                               against cold O_DIRECT reads and resolves every
                               bad page to a physical frame via pagemap.
tools/badram.rs                Board B canary. 768 MiB mlocked, hash-verified,
                               asserts its own locked size, re-reads and
                               rewrites every fault before reporting it.
tools/pfnspread.py             the control in file 04.

Note on tools/badram.rs: it has a fault-injection mode used to prove the checker
fires. It was OFF for every capture here - `inject:0` is recorded on all 8
service starts in 11-captures-raw.jsonl. We mention it so you do not have to
wonder.

----------------------------------------------------------------------
THE ONE THING TO READ IF YOU READ NOTHING ELSE
----------------------------------------------------------------------
04-pagecache-control.txt. A fault distribution is only interesting if you know
what the null looks like, and that file measures the null instead of assuming it.
