From 50b02c76e0243b5bce7274d43d5315312ce32cd4 Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 28 Sep 2026 13:51:19 +0200 Subject: [PATCH 1/3] Disable ftruncate_flush_race behind its issue, and file the timeout verdict's blind spot The orchestrator's nightly reproduced the same failure on PR #572 at 87629411, whose diff is a firmware selection change that never touches the VFS. A flaky test is disabled at once, never re-run. That run also showed wait_for_ready (tests/common/qemu.rs:5157) reading the 16550 log only when the ready marker is not the default one: a boot that panics before virtio-console comes up writes only to that file, and the timeout's own panic quotes stdio alone, so the panic line never reached the verdict. Filed as a defect for the harness to fix. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j --- ...tes-stdio-alone-and-never-the-16550-log.md | 31 +++++++++++++++++++ ...eds-intermittently-and-nothing-says-why.md | 9 ++++-- src/redlist.rs | 4 +++ 3 files changed, 42 insertions(+), 2 deletions(-) create mode 100644 issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md diff --git a/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md new file mode 100644 index 00000000000..7393fe9ad94 --- /dev/null +++ b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md @@ -0,0 +1,31 @@ +--- +status: open +kind: defect +opened: 2026-09-28 +--- + +# A boot timeout's verdict quotes stdio alone, so an early kernel panic that only reached the 16550 log is invisible in it + +`wait_for_ready` (`tests/common/qemu.rs`) reads the 16550 log (`uart_log`) +back only inside the `Err(RecvTimeoutError::Timeout)` arm's `!panic_aborts` +check — true only when the ready marker asked for is not `DEFAULT_READY`. A +boot waiting on the default marker never takes that arm, so when the boot +timeout fires (`start.elapsed() > boot_timeout`) its panic quotes only `seen`, +the lines collected from stdio, and never the 16550 file. + +A guest that panics before virtio-console comes up writes that panic to the +16550 alone — the comment above the `Timeout` arm says so: "A guest that dies +before virtio-console init never reaches stdio at all; the UART file is the +only channel it has." So the one case that comment describes is exactly the +case the timeout's own panic message cannot see: the verdict says "Boot timed +out waiting for ===READY===; the console carried: nothing at all," and the +line that killed the boot sits unread in a file next to it. + +Evidence: PR #572's control run at `87629411`. The 16550 log held `EARLY +PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of +4096 bytes failed`, and the verdict said "Boot timed out waiting for +===READY===", quoting stdio alone; the panic line never appeared in it. + +**Exit**: the timeout verdict always quotes the 16550 file's tail too, shown +by a test that stages an early panic. Owner: `tests/common/qemu.rs`, held by +the orchestrator. diff --git a/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md b/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md index a4748478b38..492eb5dcbca 100644 --- a/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md +++ b/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md @@ -1,5 +1,5 @@ --- -status: open +status: expected-red kind: tooling opened: 2026-09-01 --- @@ -42,4 +42,9 @@ the loop is one-sided precisely because a sleep can overshoot. Whoever takes this decides what to measure; this entry is the rate and the refutation, not a design. -`cargo run -- --known-red ftruncate_flush_race` says `NOT ON THE LIST`. +Red again in the orchestrator's nightly for PR #572 at `87629411`: "the +truncate did not serialise with the stalled flush". #572's diff is a firmware +selection change; it does not touch the VFS. + +A flaky test is disabled at once: `src/redlist.rs` now carries this test, and +`cargo run -- --known-red ftruncate_flush_race` says `YES, disabled`. diff --git a/src/redlist.rs b/src/redlist.rs index 8a148a67b2e..cfe0d71d331 100644 --- a/src/redlist.rs +++ b/src/redlist.rs @@ -35,6 +35,10 @@ pub const DISABLED: &[Disabled] = &[ }, Disabled { test: "desktop_window_child", issue: "issues/kernel/desktop-window-child-freeze.md" }, Disabled { test: "doom_sound_flood", issue: "issues/audio/doom-sound-flood-played-full-scale-once.md" }, + Disabled { + test: "ftruncate_flush_race", + issue: "issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md", + }, Disabled { test: "handle_basic", issue: "issues/kernel/deferred-release-outlives-its-syscall.md" }, Disabled { test: "handle_kill_policy", From f62fd625a7c07a5040034f109d7c01e28264fc82 Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 28 Sep 2026 14:21:56 +0200 Subject: [PATCH 2/3] Give the ftruncate issue an owner and a checkable exit, move the harness issue to kind: tooling with a status that agrees with its owner, and reuse the Disconnected arm's uart_log read instead of adding a second one The ftruncate-flush-race issue named a rate and a refutation but nothing owed: it now names the actuator's owner and an exit a machine can check (the capture starts holding when set_len entered the kernel relative to the stall's start). Its two misleading sentences about #572 and about the redlist disable are deleted rather than reworded. The boot-timeout-verdict issue is the development machine, not the OS, so it moves to kind: tooling per issues/README.md, and its status moves to assigned to agree with its "held by the orchestrator" owner line. Its false claim that wait_for_ready reads uart_log only inside the Timeout arm is deleted (the Disconnected arm reads it too), and the paragraph that quotes a source comment verbatim and gives a verdict example the evidence run contradicts is deleted. Its exit condition now points at the Disconnected arm's existing fs::read_to_string(uart_log) read rather than asking for a second reader. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j --- ...tes-stdio-alone-and-never-the-16550-log.md | 23 ++++++------------- ...eds-intermittently-and-nothing-says-why.md | 17 ++++++++++---- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md index 7393fe9ad94..7da2e944ed9 100644 --- a/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md +++ b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md @@ -1,31 +1,22 @@ --- -status: open -kind: defect +status: assigned +kind: tooling opened: 2026-09-28 --- # A boot timeout's verdict quotes stdio alone, so an early kernel panic that only reached the 16550 log is invisible in it -`wait_for_ready` (`tests/common/qemu.rs`) reads the 16550 log (`uart_log`) -back only inside the `Err(RecvTimeoutError::Timeout)` arm's `!panic_aborts` -check — true only when the ready marker asked for is not `DEFAULT_READY`. A -boot waiting on the default marker never takes that arm, so when the boot +A boot waiting on the default marker never takes that arm, so when the boot timeout fires (`start.elapsed() > boot_timeout`) its panic quotes only `seen`, the lines collected from stdio, and never the 16550 file. -A guest that panics before virtio-console comes up writes that panic to the -16550 alone — the comment above the `Timeout` arm says so: "A guest that dies -before virtio-console init never reaches stdio at all; the UART file is the -only channel it has." So the one case that comment describes is exactly the -case the timeout's own panic message cannot see: the verdict says "Boot timed -out waiting for ===READY===; the console carried: nothing at all," and the -line that killed the boot sits unread in a file next to it. - Evidence: PR #572's control run at `87629411`. The 16550 log held `EARLY PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of 4096 bytes failed`, and the verdict said "Boot timed out waiting for ===READY===", quoting stdio alone; the panic line never appeared in it. -**Exit**: the timeout verdict always quotes the 16550 file's tail too, shown -by a test that stages an early panic. Owner: `tests/common/qemu.rs`, held by +**Exit**: the timeout verdict quotes the 16550 file's tail the same way the +`Disconnected` arm already does — `fs::read_to_string(uart_log)` +(`tests/common/qemu.rs:5147`) — rather than adding a second reader, shown by +a test that stages an early panic. Owner: `tests/common/qemu.rs`, held by the orchestrator. diff --git a/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md b/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md index 492eb5dcbca..e0905d05e12 100644 --- a/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md +++ b/issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md @@ -43,8 +43,17 @@ this decides what to measure; this entry is the rate and the refutation, not a design. Red again in the orchestrator's nightly for PR #572 at `87629411`: "the -truncate did not serialise with the stalled flush". #572's diff is a firmware -selection change; it does not touch the VFS. +truncate did not serialise with the stalled flush". -A flaky test is disabled at once: `src/redlist.rs` now carries this test, and -`cargo run -- --known-red ftruncate_flush_race` says `YES, disabled`. +## Exit condition + +The capture holds when `set_len` entered the kernel relative to the stall's +start, so a short `waited` is machine-distinguishable from a retry, and +`ftruncate_flush_race` is green against that instrument on the dev host across +the counts in the table above. Then this file and its `src/redlist.rs` row are +deleted. + +## Owner + +The `ftruncate-flush-stall` actuator, `tests/common/volumes.rs`; held by the +orchestrator. From de3f9a3f95262fa649802f884e2db055701fc7ba Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 28 Sep 2026 14:24:37 +0200 Subject: [PATCH 3/3] Delete the harness issue's sentence naming "that arm" instead of leaving it reworded Line-bounded deletion of the false claim about wait_for_ready's uart_log read left a following sentence whose "that arm" had no antecedent. Problematic prose is deleted, not reworded: the whole sentence goes. The title already states the defect and the Evidence/Exit paragraphs already carry the rest. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j --- ...eout-verdict-quotes-stdio-alone-and-never-the-16550-log.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md index 7da2e944ed9..2cf6986ef16 100644 --- a/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md +++ b/issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md @@ -6,10 +6,6 @@ opened: 2026-09-28 # A boot timeout's verdict quotes stdio alone, so an early kernel panic that only reached the 16550 log is invisible in it -A boot waiting on the default marker never takes that arm, so when the boot -timeout fires (`start.elapsed() > boot_timeout`) its panic quotes only `seen`, -the lines collected from stdio, and never the 16550 file. - Evidence: PR #572's control run at `87629411`. The 16550 log held `EARLY PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of 4096 bytes failed`, and the verdict said "Boot timed out waiting for