aarch64: kernel-mode near-null DATA_ABORT — FAR=0x2, ELR in kernel text, ESR=0x96000005 DFSC=0x5, 1/100 clean cortex-a72 boots (PR-A acceptance battery)

[ryanbreen]

A new fatal field signature turned up in the T3-G PR3 (PR-A) acceptance battery on
fix/producer-corruption-family @ 14272b9a. It matches nothing filed, so it is filed on its own
rather than folded into any tolerated bucket.

Field signature

[DATA_ABORT] FAR=0x2 ELR=0xffff0000404e80a0 ESR=0x96000005 DFSC=0x5 TTBR0=0x10000440dd000 from_el0=0
[FATAL_REGS] label=DATA_ABORT cpu=0 spsr=0x600000c5 esr=0x96000005 far=0x2 elr=0xffff0000404e80a0 sp=0xffff0000431ffd90
  x0=0xffff000040800338 x1=0xffff0000431ffec8 x2=0x8 x3=0x68
  x4=0x0 x5=0x0 x6=0x0 x7=0x0
  x8=0x0 x9=0x2 x10=0x7fa42 x11=0x0
  x12=0xffffffffffff00b8 x13=0x50 x14=0x4b8 x15=0xffffffffffff00b8
  x16=0x2 x17=0x0 x18=0x0 x19=0xffff000040800338
  x20=0x1 x21=0xffff0000431ffe58 x22=0xffff000050393de8 x23=0xffff000050397fb0
  x24=0xffff000040606938 x25=0xffff000040606908 x26=0xffff000040606920 x27=0xffff00005032c708
  x28=0xffff00005032c708 x29=0xffff0000406068f0 x30=0xffff00004040a2e0
  percpu_kst=0xffff000043200000 user_rsp_scratch=0xffff0000431ffd90
  STACK=boot_cpu0
[DATA_ABORT] kernel-mode fault, deferring process cleanup
[DATA_ABORT] deferred_tid=9 queued=1

A kernel-mode (EL1, from_el0=0) data abort on a translation fault at level 1 (DFSC=0x5) against
a near-null address, FAR=0x2. The ELR is a valid kernel-text address and the two registers
holding 0x2 (x9, x16) point at a small-integer/uninitialised-pointer dereference rather than a
wild pointer. x19 = 0xffff000040800338 is a SCHEDULER-region address; DAIF in spsr=0x600000c5
shows the fault was taken with interrupts masked, on CPU 0, on the boot CPU stack
(STACK=boot_cpu0), 6 s into the boot.

Why it is not one of the filed faces

filed	why this is not it
#633	[PC_ALIGN], EL0, ELR is a small tid — this is EL1, a data abort, valid ELR
#635	FAR == ELR, instruction abort ESR=0x8600000e — this is FAR != ELR, data abort
#637	EL0 resumed at a kernel address, from_el0=1 — this is from_el0=0
#576 / #626	zero PC (ELR=0, ESR=0x86000005 / 0x8600000d) — ELR here is valid kernel text
#612	wild-context DATA_ABORT in the FAR=0x292 region — FAR=0x2 is a different address class
#639	FAR=0x210 ELR=0x0 with a kernel VA in spsr (architecturally impossible dump class) — this dump is internally consistent
#640	end-of-RAM external abort, ESR=0x96000010 DFSC=0x10 — different fault class

Rate and provenance

1 boot in 100 on the clean cortex-a72 profile of the PR-A battery (196/200 GREEN overall; the
other three non-GREEN boots were pre-adjudicated #555, pre-adjudicated #613, and one attributed
#635). Not reproduced on the max profile (0/100), the starved legs (0/100), the service-sequence
gate (0/50) or the strict gate (0/60). The gate correctly bucketed it UNATTRIBUTED; no tolerance
was added for it, so it fails the gate wherever it recurs.

Serial preserved in-repo:
docs/planning/teardown-unification/pr3-acceptance-battery-serials/clean-cortex100-boot97-far0x2-null-data-abort.txt
(with the other three battery serials and a provenance README beside it).

What is not known

The faulting instruction is not resolved to a symbol here — the address resolution needs the exact
boot_tests-profile ELF of 14272b9a, and no producer for the 0x2 value is named. Nothing in
PR-A contains or measures this face: [RESUME_PC_REFUSED: count was 0 on this boot, as on all 330
boots of the battery.

[ryanbreen]

Serial location precision: the preserved serial and its provenance README are on branch fix/producer-corruption-family (commit 40082bdb, PR #642) at docs/planning/teardown-unification/pr3-acceptance-battery-serials/clean-cortex100-boot97-far0x2-null-data-abort.txt; they reach main when that PR merges.

[ryanbreen]

Second occurrence — T3-G PR3 (PR-A) round-4 service-sequence gate, cortex-a72 boot 21

Same field signature, different CPU, different ELR, different boot phase. Recorded here so the issue
carries both faces rather than only the one it was filed from.

[DATA_ABORT] FAR=0x2 ELR=0xffff000040846998 ESR=0x96000005 DFSC=0x5 TTBR0=0x1000044137000 from_el0=0
[FATAL_REGS] label=DATA_ABORT cpu=3 spsr=0xffff000040488ae8 esr=0x96000005 far=0x2 elr=0xffff000040846998 sp=0xffff0000431ffb00
  x0=0xffff000040800228 x1=0xffff000040800230 x2=0x4b5 x3=0x4
  x4=0xffff000040800220 x5=0xffff000040800220 x6=0x0 x7=0xffff00004040af24
  x8=0xffff0000408003c0 x9=0xffff000040918000 x10=0xffff000040918000 x11=0xffff000040918c00
  x12=0xffff000040800008 x13=0x0 x14=0x0 x15=0x8
  x16=0xffff000040800008 x17=0x0 x18=0xffff000040488ae8 x19=0xffff000040846998
  x20=0xffff000040488ae8 x21=0xffff000040846998 x22=0x1 x23=0x0
  x24=0x1 x25=0xffff0000408509b8 x26=0x8 x27=0x0
  x28=0x8 x29=0x0 x30=0xffff00004044f800
[DATA_ABORT] kernel-mode fault, deferring process cleanup
[DATA_ABORT] deferred_tid=1212 queued=1

Serial preserved in-repo:
docs/planning/teardown-unification/pr3-round4-serials/ss25-cortex-a72-boot21-641-far0x2-esr0x96000005.txt

What matches the filed signature

FAR=0x2, ESR=0x96000005, DFSC=0x5 (level-1 translation fault), from_el0=0, and an ELR that is
a valid kernel-text address — field for field the signature this issue is filed at. It is a different
ELR from the filed one (0xffff000040846998 here vs 0xffff0000404e80a0 in the original), and a
different CPU (3 vs 0), so the fault site is not pinned to one instruction by these two samples.

What differs, stated rather than smoothed over

• spsr=0xffff000040488ae8 is a kernel VA, not a PSTATE word. The filed occurrence carried a
  plausible spsr=0x600000c5. Here spsr holds the same value as x18 and x20. That is the
  aarch64: [DATA_ABORT] FAR=0x210 ELR=0x0 ESR=0x96000005 — strict-gate run 1 boot 10, matches no filed signature #639 dump class (a [FATAL_REGS] record that is not internally consistent), showing up on a
  aarch64: kernel-mode near-null DATA_ABORT — FAR=0x2, ELR in kernel text, ESR=0x96000005 DFSC=0x5, 1/100 clean cortex-a72 boots (PR-A acceptance battery) #641-signature fault. Whether the dump is wrong or the exception state really was clobbered is not
  established by this serial, and nothing here decides it. Recorded because the field-keyed
  classification below looks only at FAR/ESR/DFSC/from_el0/ELR and would never surface it.
• x19 and x21 both hold the ELR; x2=0x4b5, which is the exact ELR value aarch64: userspace PC-alignment fault at ELR=0x4b5 FAR=0x5 followed by a LayoutError panic in the heap allocator (1/25 SS-gate boots, cortex-a72) #625 is filed at.
  Noted as an observation, not a claim of relatedness.

Rate

• Round-1 PR-A acceptance battery: 1 in 100 clean cortex-a72 boots (0/100 max, 0/100 starved,
  0/50 service-sequence, 0/60 strict).
• Round-4 service-sequence gate: 1 in 50 (cortex-a72 24/25, max 25/25).

Two single occurrences under different loads. Neither pins a rate, and they are not combined into
one.

Gate treatment (T3-G PR3 round 5, coordinator ruling R49)

The service-sequence gate's classifier now has a field-keyed #641 bucket, and it is an
attribution, not a tolerance: count_641 is in the same per-profile FAIL condition as #576 and
#626, so a boot carrying this signature fails the gate exactly as it did when it scored
UNATTRIBUTED. The only change is that a recurrence is now reported under this issue instead of as
"matches no filed signature". The key requires FAR=0x2 + ESR=0x96000005 (DFSC is that ESR's low
six bits) + from_el0=0 + a single kernel-text ELR across the whole record set; a serial with the
same FAR/ESR but a non-kernel-text ELR, or with two records that disagree about ELR, stays
UNATTRIBUTED.

#641 remains open and unfixed. No round of PR-A touched any path this signature lives on.

[ryanbreen]

E2 200-boot battery — restated at its measured ceiling, stays OPEN

Evaluated against main @ f96ea36c (baseline of record: docs/planning/t3g-prb/GATE-BASELINE-f96ea36c.md, PR #649). Restatement is the pre-registered outcome for this issue; a close was never on the table for it and is not taken.

The measurement

One 200-boot service-sequence battery (--profile both --boots 100 --rebuild), single sequential QEMU, no re-runs: 641 bucket 0/200, all 200 boots GREEN. The bucket is field-keyed (FAR=0x2 + ESR=0x96000005 + from_el0=0 + a single kernel-text ELR across the whole record set) and, per ruling R49, is an attribution and not a tolerance — count_641 sits in the same per-profile FAIL condition as #576 and #626, so an occurrence would have failed its profile.

The rate, restated

Evidence	Boots	Occurrences
PR-A round-1 acceptance battery (clean cortex-a72 leg)	100	1
PR-A round-4 service-sequence gate (cortex-a72)	50	1
E2 battery at f96ea36c	200	0

• P(0 | 1%, 200) = 0.134, N₉₅ = 298. This battery is fully consistent with the defect being unchanged. It is not evidence of repair.
• Measured ceiling from this battery alone (rule of three): 95% upper bound = 1 - 0.05^(1/200) = 1.49%.
• Pooled point estimate across the PR-A batteries and this one: 2 events in roughly 1,000 boots ≈ 0.2%.

Neither number is zero, and the two prior occurrences remain two single observations under different loads that do not pin a rate between them.

Mechanism: unaddressed

Nothing merged since this issue was filed touches the path this signature lives on — the standing statement from the round-4 review is unchanged, and PR #649's baseline confirms no leg at f96ea36c addressed it. The spsr-holding-a-kernel-VA anomaly recorded on the second occurrence (the #639 dump class appearing on a #641-signature fault) is likewise undecided.

Verdict

#641 stays OPEN and gate-failing, restated at a 95% ceiling of ≤1.5% and a pooled point estimate of ~0.2%. A close requires the filed mechanism to be addressed, not a larger clean sample.