aarch64: disagreeing INSTRUCTION_ABORT record pairs in one serial score UNATTRIBUTED on the SS gate (~2/400)

[ryanbreen]

Signature

The service-sequence gate classifier's abort scanner finds two INSTRUCTION_ABORT records with
different field sets in the same serial, e.g.:

• far/elr/esr = 0x0 0x0 0x86000005 (the #576 field-exact shape) paired with
  far/elr/esr = 0x10 0x321c0508eb09039f 0x86000005 in the same boot (max profile, clean leg,
  boot 17).
• far/elr/esr = 0x0 0x28 0x86000005 paired with
  far/elr/esr = 0xffff000054242320 0xffff000054242320 0x8600000e in the same boot (max profile,
  starved leg, boot 64).

By classifier design a disagreement between two abort records in one serial is never folded into a
tolerated bucket (correctly — collapsing two different faults into one signature would hide whichever
one is novel), so both boots score UNATTRIBUTED and fail the gate. Neither ELR/FAR pair on its own
matches a pre-adjudicated bucket beyond the coincidental #576-shape first record in the boot-17
case.

Rate

2/400 in the round-2 400-boot clean+starved battery on fix/589-deferred-requeue-drift @
33f68f52 (one in the clean leg, one in the starved leg). Reduced-to-background relative to the
signatures this branch's fix targets, but no longer absorbable into an existing bucket — it costs the
gate two hard UNATTRIBUTED FAILs with no issue number to point at.

What's not established

Whether this is two genuinely distinct EL1 instruction aborts occurring in sequence within one boot
(a real double-fault-class defect), or a serial-capture/log-interleaving artifact that makes one
abort's trace look like two records. The raw serials show heavily interleaved/garbled
[TRACE] CPUn ... lines around the abort in both cases (byte-level interleaving consistent with
concurrent unsynchronized trace-buffer printing across CPUs), which is at least a contributing
capture-fidelity problem independent of whatever the underlying fault is.

Preserved serials

• scratchpad/589fix/preserved-serials-r2/clean100-max-boot17-UNATTRIBUTED.txt
• scratchpad/589fix/preserved-serials-r2/starved100-max-boot64-UNATTRIBUTED.txt

(round-2 mac gate slot, docs/planning/teardown-unification/589-ROUND2-PARTITION-2026-08-20.md
§6/§7)

[ryanbreen]

Cross-reference — another exemplar, from the PR #634 starved gate

The PR #634 round-1 starved-gate leg (100 boots, -cpu max + -cpu cortex-a72, 14 host yes hogs
at nice -n 19) produced one non-GREEN boot, and it is this face rather than a new one. Recording it
here so the rate has another data point and so the PR's attribution is auditable.

Serial: docs/planning/teardown-unification/607-576-serials/gate-starved100-max-boot3-disagreeing-pair-613.txt
(-cpu max, boot 3 of 50). Two INSTRUCTION_ABORT records in the one boot, on the same cpu=2,
disagreeing:

:639  [INSTRUCTION_ABORT] FAR=0xffff000040800008 ELR=0xffff00004040b064 ESR=0x8600000e IFSC=0xe TTBR0=0x100004406c000 from_el0=0
:640  [FATAL_REGS] label=INSTRUCTION_ABORT cpu=2 spsr=0x4040 esr=0x8600000e far=0xffff000040800008 elr=0xffff00004040b064 sp=0xffff000054274f20
:5107 [FATAL_REGS] label=INSTRUCTION_ABORT cpu=2 spsr=0x200023c5 esr=0x8600000d far=0x0 elr=0x0 sp=0xffff000054274e10

The second record is byte-identical to #626's filed header (far=0x0 elr=0x0 esr=0x8600000d); the
first carries ESR=0x8600000e at two different live addresses. The service-sequence gate's
anti-disagreement rule keeps a disagreeing boot out of every named bucket, so this boot scored
UNATTRIBUTED and both 576 and 626 read 0 for the run — the classifier behaving as designed,
and the reason this issue exists.

This is not the new single-record face filed as #635 (FAR == ELR == x30 == x29 at one kernel
stack address, 3/200 clean boots, one self-consistent record per boot). It shares only the ESR/IFSC.
The two are cross-referenced in both directions.

Running tally with this run included: the previously filed ~2/400, plus 1/100 here.

The same boot also carries an EL1 [PC_ALIGN] ELR=0x4b1 FAR=0x7 from_el0=0 cpu=2 record at :614,
appended to #633 (which was filed as an EL0-only face).