BOARD B - 17 INSTRUMENTED DRAM FAULT CAPTURES
AXON V0.2, 8 GiB LPDDR4X, no ECC, kernel 6.1.75-axon-fleet4
Captured by a resident 768 MiB mlocked hash-verified canary. Raw records are in
11-captures-raw.jsonl - every field below is derived from them, nothing is retyped.
==========================================================================

1. WHEN, AND UNDER WHAT CONDITIONS
--------------------------------------------------------------------------
  2026-09-16T18:53:22Z  pass 316  test w8-hash  10 faults  frame(s) 0x1a1fa2000, 0x1a1fa3000
  2026-09-17T01:55:03Z  pass 426  test w64-hash  7 faults  frame(s) 0x1a3e1d000

  SoC temperature at capture : 38.8 - 39.8 C   (idle-cool; not thermal)
  DRAM clock at capture      : 2112 MHz
  DRAM governor              : performance, pinned. 9 transitions in 4 days uptime.
  -> These faults happened with the DRAM clock essentially STATIC. Whatever this is,
     frequency switching is not the trigger.

2. THE FAULTS ARE REAL, NOT INSTRUMENT ARTEFACTS
--------------------------------------------------------------------------
  inject flag on all 8 canary starts     : 0  (no synthetic faults were requested)
  re-read 3x and got the SAME wrong value: 17 of 17
     -> the wrong value was genuinely stored, not a one-shot read glitch
  rewriting the word restored the truth   : 17 of 17
  sticky (cell stuck at the wrong value)  : 0 of 17
     -> a TRANSIENT retention/read failure, not a dead cell. This is why a plain
        memtester pass can come back clean on a board that is genuinely faulting.

3. WHICH FRAMES
--------------------------------------------------------------------------
    0x1a1fa2000   5 fault(s)
    0x1a1fa3000   5 fault(s)
    0x1a3e1d000   7 fault(s)
  3 distinct frames = 12 KiB = 0.00015% of 7,926 MiB
  adjacent pairs among them: 1  (same 8 KiB-pair structure Board A shows)
  span: 0x1a1fa2000 .. 0x1a3e1d000 = 30.5 MiB,
  inside the 0x100000000-0x1ffffffff System RAM bank - the same bank as Board A,
  though a different region of it.

4. BIT-LEVEL STRUCTURE - THE PART WE WOULD MOST LIKE EXPLAINED
--------------------------------------------------------------------------
  byte position within the 64-bit word that flipped:
    byte 0:    0  
    byte 1:    0  
    byte 2:    0  
    byte 3:    0  
    byte 4:   16  ################
    byte 5:    0  
    byte 6:   14  ##############
    byte 7:    0  
  -> ONLY bytes 4 and 6. Never 0-3, never 5, never 7.

  physical address mod 32 of the faulting word: {0: 17}
  Every faulting 64-bit word starts on a 32-byte boundary, so byte 4 and byte 6 are
  absolute offsets 4 and 6 within the 32-byte LPDDR4X BL16 burst.

  WE CHECKED THAT THIS IS NOT A SAMPLING ARTEFACT. The canary verifies EVERY 64-bit
  word in the segment. It alternates traversal ORDER between sequential and a
  64 KiB-strided walk (to force row activations between reads), but both branches
  visit every word - we read the source to confirm it rather than assuming. It could
  therefore have reported a fault at mod 32 = 8, 16 or 24, and never once did.
  If faults were spread evenly over the four word slots in a burst, the chance of
  all 17 landing in slot 0 is (1/4)^17, about 6e-11.

  direction of every flipped bit: SET 2, CLEARED 44
  -> 96% CLEARS. Board A is ~96% SETS. Opposite polarity,
     which is what two independent device faults look like - not one design issue.

  bits flipped per 64-bit word:
    2 bits: 11 record(s)
    4 bits: 6 record(s)
  -> always even, always 2 or 4. Never a single-bit flip.

5. HOW THIS COMPARES TO BOARD A - STATED CAREFULLY
--------------------------------------------------------------------------
  Every capture we can still re-verify, on either board, by either instrument:

    Board A, 2026-09-08, page-cache detector : offsets 8, 10, 12, 14   (even)
    Board B, 2026-09-16/17, resident canary  : offsets 4 and 6         (even)
    Board B, memtester run                   : offset 22               (even)

  RK3588 drives 16-bit LPDDR4X channels, so an even byte offset is the LOW byte of
  the 16-bit word - DQ0-DQ7. Both tools compare every byte (Board A) or every 64-bit
  word (Board B) in their buffers, so both were free to report odd offsets, and in
  these captures neither did.

  TWO RECORDS DO NOT FIT, AND WE ARE NOT HIDING THEM:

    Board B, 2026-09-13, corrupted build artefact : offset 7           (ODD)
    Board A, 2026-08-20, earlier fault epoch      : offsets 9, 11      (ODD)

  The build-artefact byte is a different regime - that corruption reached DISK, so
  the flip could have occurred anywhere on the writeback path. The 2026-08-20 epoch
  is recorded in our own notes, but that log no longer exists on the board, so we
  cannot re-verify it and we rest no argument on it.

  THE CLAIM WE ACTUALLY STAND BEHIND is the weaker one, and it holds across all of
  the above: faults are BYTE-LANE CONFINED. In no single capture did both bytes of a
  16-bit word go bad together - it is always one lane of the pair, never the pair.
  WHICH lane has varied between capture epochs and between instruments, and we have
  no explanation for that.

  Lane confinement plus 32-byte-aligned words is the structure we would most like a
  Rockchip DDR engineer to look at. Ambient soft errors have no reason to respect a
  DQ lane boundary; a marginal lane, a training result or a write-leveling margin
  does.
