On the aarch64 strict gate, 1 of 40 boots at BUILD_ID 006a9c7cb301c7
(fix/819-fcntl-oracle-arming-rendezvous, second origin/main merge, run2b
boot 14) printed:
[STRAND_INJECT_ORACLE:aarch64:legA_exercised=1:legA_recovered=1:legB_exercised=0:legB_recovered=0:stranded=0]
docker/qemu/run-aarch64-boot-test-strict.sh's STRAND_INJECT_ORACLE_PATTERN
requires legB_exercised=1:legB_recovered=1, so this boot's gate verdict was
[FAIL] Boot 14: Scheduler strand injection oracle marker missing or failed.
legA exercised and recovered normally; only legB (the second injection
leg, armed via INJECT_B_ARMED/fired via INJECT_B_FIRED in
kernel/src/task/strand_oracle.rs) did not fire this boot. The rest of the
boot completed normally: [BOOT_TESTS:PASS] printed twice,
FCNTL_PM_CONTENTION_ORACLE in the same serial read PASS, and the kernel
kept running well past the completion marker (bsshd, xhci_counters,
heartbeats).
The other 39 of 40 boots in the same two-run battery (across both
origin/main merges of that landing) printed
legB_exercised=1:legB_recovered=1 -- this looks like a rare, timing-window
miss on leg B's own arming/firing rather than a stranding regression
(stranded=0 in the same line). Filed rather than investigated further:
out of scope for the branch that surfaced it, which does not touch
kernel/src/task/strand_oracle.rs or kernel/src/arch_impl/aarch64/context_switch.rs.
Possibly related: #624 (STRAND_INJECT_ORACLE marker never printed on a
starved profile -- a different failure shape, marker absent rather than
present with legB_exercised=0, but the same oracle).
Serial preserved at (this session's scratchpad; ask for a copy if it has
since been cleaned up):
/private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/fcntl-arm-serials/unattributed-strand-inject/run2b-boot14-legB-not-exercised.txt
On the aarch64 strict gate, 1 of 40 boots at BUILD_ID
006a9c7cb301c7(
fix/819-fcntl-oracle-arming-rendezvous, secondorigin/mainmerge, run2bboot 14) printed:
docker/qemu/run-aarch64-boot-test-strict.sh'sSTRAND_INJECT_ORACLE_PATTERNrequires
legB_exercised=1:legB_recovered=1, so this boot's gate verdict was[FAIL] Boot 14: Scheduler strand injection oracle marker missing or failed.legAexercised and recovered normally; onlylegB(the second injectionleg, armed via
INJECT_B_ARMED/fired viaINJECT_B_FIREDinkernel/src/task/strand_oracle.rs) did not fire this boot. The rest of theboot completed normally:
[BOOT_TESTS:PASS]printed twice,FCNTL_PM_CONTENTION_ORACLEin the same serial readPASS, and the kernelkept running well past the completion marker (bsshd, xhci_counters,
heartbeats).
The other 39 of 40 boots in the same two-run battery (across both
origin/mainmerges of that landing) printedlegB_exercised=1:legB_recovered=1-- this looks like a rare, timing-windowmiss on leg B's own arming/firing rather than a stranding regression
(
stranded=0in the same line). Filed rather than investigated further:out of scope for the branch that surfaced it, which does not touch
kernel/src/task/strand_oracle.rsorkernel/src/arch_impl/aarch64/context_switch.rs.Possibly related: #624 (
STRAND_INJECT_ORACLE marker never printedon astarved profile -- a different failure shape, marker absent rather than
present with
legB_exercised=0, but the same oracle).Serial preserved at (this session's scratchpad; ask for a copy if it has
since been cleaned up):
/private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/fcntl-arm-serials/unattributed-strand-inject/run2b-boot14-legB-not-exercised.txt