You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Test 3: FAIL (x86 userspace verdict rejected the run)
x86 userspace gate: FAIL - failing process is not allowlisted: clock_gettime_test
TEST_TALLY: exited=19 nonzero=1 failed=[clock_gettime_test:1]
🚨 TEST RUNNER: FAILED - 1 of 19 userspace processes exited nonzero 🚨
Every other userspace process in that boot exited 0, the boot completed (USERSPACE TEST COMPLETE
present, exited=19 matches the profile's expected count), and no other marker in the boot is
abnormal. So this is a single userspace assertion failing, not a crash and not a hang.
clock_gettime_test exits non-zero when one of its monotonic/realtime assertions fails; the boot log
alone does not say which, which is the first thing to fix (below).
Where it was seen
Observed once during the R37 x86 A/B for the #609 branch, on the pre-fix control commit 8bcc1999: 1 occurrence in 70 control boots, 0 in 35 boots at branch HEAD d28407ae. It is filed
because it is an x86 red with no issue of its own, not because it is attributable to that branch.
Evidence gap
No serial preserved — /tmp/breenix_boot_N/ is overwritten by the next round and the preservation
wrapper was added to the following battery; 30 further control boots with preservation did not
reproduce it. This issue carries the round log and the rate.
Signature
docker/qemu/run-boot-parallel.sh 5on beast (breenix-x86Incus container,-smp 1,testing,external_test_binsprofile), 1 boot:Every other userspace process in that boot exited 0, the boot completed (
USERSPACE TEST COMPLETEpresent,
exited=19matches the profile's expected count), and no other marker in the boot isabnormal. So this is a single userspace assertion failing, not a crash and not a hang.
clock_gettime_testexits non-zero when one of its monotonic/realtime assertions fails; the boot logalone does not say which, which is the first thing to fix (below).
Where it was seen
Observed once during the R37 x86 A/B for the #609 branch, on the pre-fix control commit
8bcc1999: 1 occurrence in 70 control boots, 0 in 35 boots at branch HEADd28407ae. It is filedbecause it is an x86 red with no issue of its own, not because it is attributable to that branch.
Evidence gap
No serial preserved —
/tmp/breenix_boot_N/is overwritten by the next round and the preservationwrapper was added to the following battery; 30 further control boots with preservation did not
reproduce it. This issue carries the round log and the rate.
Suggested first moves
clock_gettime_testprint which assertion failed and the two timestamps involved before itexits non-zero — a bare
exit(1)from a timing test is unattributable by construction, and this isthe second timing-adjacent oracle this campaign has had to reverse-engineer from a bare status
(see aarch64: FUTEX_HANDOFF stage-3 reds the strict gate with stage3_elapsed_ok=0 (49 ms of a 50 ms wait) — the oracle's elapsed anchor is stamped later than the deadline it is compared against #627 for the futex one).
run-boot-parallel.sh(also asked for by x86: run-boot-parallel boots that never reach USERSPACE TEST COMPLETE (2/70 at the r1-era control commit, no serial preserved) #630).Provenance
Branch
fix/609-early-kthread-dispatch, R37 amend slot (T3-G PR1 r2 review finding R2-B4, controlleg). Recorded in
docs/planning/teardown-unification/609-RCA-RETRACTION-2026-08-21.md§6.5.