issues: close the load-only records whose tests are deleted by Japabu · Pull Request #1171 · ToyOSOrg/ToyOS

Japabu · 2026-11-04T09:29:28Z

Problem

Intermittent records named tests that have since been deleted. A record whose only reproduction is gone, and that was seen only on a loaded host, tracks nothing; others still describe a real defect but point at a test that no longer exists.

Change

Records only, plus one doc line in tests/toyos.rs that cited a closed record.

Closed, seen only under host load, test deleted (one line each in the commit message): a-netcase-boot-under-host-load-…, a-shared-boot-stopped-answering-…, both consent-prompts-…, log-reserve-window-negative-…, metal-job-reboot-drained-…, smp-ap-hole-and-log-reserve-window-…, stdio-buffering-saw-one-long-line-…, syscall-window-nmi-shortfalls-…, the-console-loses-typed-keystrokes-under-host-load (its mechanism stays tracked in a-command-typed-through-qmp-arrives-truncated-under-host-load), and a-syscall-panic-reset-the-guest-announced-and-qemu-never-saw (red once on a loaded host, its reset_now path gone, nothing reproduces it, and metal has no QEMU reset event to retire it).
Citations moved into the records that relied on the closed files: parallel-tests-red-under-other-suites, guest-tests-a-loaded-host-can-turn-red, two-amdvi-boots-in-a-kvm-suite-wrote-not-one-byte, two-processes-started-at-an-entry-point-nothing-had-mapped.
Real defects with no remaining test stay open and name the commit that deleted their test: so-cache-refusals-… (4505f872d) and a-double-panic-at-boots-edge-… (ad6dc0781). The double panic's owner is whoever holds the K4 stage of issues/the-kernel-still-creates-threads.md, open as kernel: no kernel thread but the idle loop; the console UART is a userland driver's (K4, K6) #1165, and its stale reproduction recipe goes.
a-holders-queued-line-can-reach-the-console-after-the-last-word cites that K4 stage by path, says only what K4 states (klogd goes, the console moves to logd, one wire's driver stays in the kernel), notes kernel: no kernel thread but the idle loop; the console UART is a userland driver's (K4, K6) #1165, and names the track's holder as its owner.
libc-childrens-tty-interrupt-can-stall-at-the-nested-shells-line gains its 2026-11-04 sighting at the nightly's shape (tests: a guest runs only where the host has a CPU for each of its vCPUs #1166's head arm, 207 s): it did not wait for host CPUs; host load was not recorded; with tests: a guest runs only where the host has a CPU for each of its vCPUs #1166's evidence link.

Checks

No build: records plus one /// line on a test function. git grep for each deleted record's slug at the head finds nothing.

🤖 Generated with Claude Code

Japabu · 2026-11-04T09:57:48Z

Review of #1171 at `ab2d8ce3c`

Assessment. This change only touches records, and its shape is right. A load-only record whose test is gone tracks nothing and should be deleted. The commit message carries why each one closed. Records that cited a closed file now keep what they used from it. Citations are clean: git grep for each of the ten slugs at the head finds nothing, and main's six moves since the base (bd1da1a26..7835695) add no new pointer. The tests/toyos.rs doc line is correct.

The ten closes hold up against the owner's policy. Every recorded red was beside other worktrees' load or at a measured high load average:

smp-ap-hole: the WouldBlock came from spawn(&[INIT_PATH]) reading init through the kernel's filesystem. That path no longer exists, because spawn_supervisor now spawns from a boot image.
shared-boot: it was re-measured and the recorded rate refuted.
the-console-loses-typed-keystrokes: its mechanism stays tracked in issues/a-command-typed-through-qmp-arrives-truncated-under-host-load.md.

No real defect is closed. The findings below are about the records that stay open and the accuracy of the text that was added.

Blockers

issues/a-double-panic-at-boots-edge-says-nothing-but-its-name.md:68 names the wrong deleting commit.
- The added line says 520c0d129 took out log_poll_outlives_a_close. On main it was removed by ad6dc0781 ("Delete log_poll_outlives_a_close, a filed flake"), which landed in The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639 at 06:17 UTC on 2026-10-01. 520c0d129 landed later, in The guest suite keeps the 21 tests only a booted machine answers; the rest are metal, host or tracked #660 at 09:19. Its branch had forked before The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639, so its diff also shows the removal, but it is not the commit that took the test out of main.
- issues/parallel-tests-red-under-other-suites.md:472 already says ad6dc0781, so the two records now contradict each other. ad6dc0781 is also the commit whose revert restores the test.
- Fix: say ad6dc0781.
issues/a-double-panic-at-boots-edge-says-nothing-but-its-name.md has no owner. The PR keeps it open on purpose as a real defect. Root CLAUDE.md requires a kept compromise to record its evidence, owner and exit. This record names an exit but no owner. Its "reproduction recipe: cargo test in two worktrees at once" is also stale: the test is gone, and tests: a guest runs only where the host has a CPU for each of its vCPUs #1166 now stops guests from sharing host CPUs. Fix: name the owner, which by its own text is the log redesign track or the orchestrator, and drop the recipe.
issues/a-holders-queued-line-can-reach-the-console-after-the-last-word.md:51-52 points at a stage that doesn't exist under the name it uses, and describes a design the stage doesn't contain.
- "small-kernel K4" does not exist. K4 is a stage of issues/the-kernel-still-creates-threads.md; the small-kernel track counts in steps and stages, and its pages never mention K4.
- "a userland UART driver fed by logkeeper" is not what K4 says. K4 moves the console to logd and states that "one wire's driver stays in the kernel whatever K4 moves". The boot's last word is written through drain_inline, which is part of that kernel path.
- issues/README.md says "Name the file."
- Fix: cite issues/the-kernel-still-creates-threads.md's K4 by path, say only what K4 states, and name that track's holder as this record's owner. The record has none today.
The exit of issues/a-syscall-panic-reset-the-guest-announced-and-qemu-never-saw.md is now unreachable as written.
- The new line at :48 says no test drives that reset. The exit's second arm (:53) is still "syscall_panic_halts runs clean often enough".
- The only planned return is metal stage B of issues/the-guest-suite-runs-only-what-no-cheaper-tier-reaches.md. Metal has no QEMU SHUTDOWN event, so it cannot retire a symptom where QEMU never saw the reset.
- The record's own facts also fit the closed set. It was red once at a 2.96x liveness width, which means a slow, loaded host. "This exact path is gone" (reset_now). Nothing measured reproduces it.
- Fix, the orchestrator's choice: close it with the load-only ten, or rewrite the exit so it names what restores a QEMU reset oracle.
issues/libc-childrens-tty-interrupt-can-stall-at-the-nested-shells-line.md:33-37 claims more than the evidence measured.
- "No other guest was admitted beside it" is not what tests: a guest runs only where the host has a CPU for each of its vCPUs #1166 measured. tests: a guest runs only where the host has a CPU for each of its vCPUs #1166 says the row "did not wait for CPUs". With TOYOS_HOST_CORES=4 and a 2-vCPU guest, another guest could hold the other two CPUs without causing any wait.
- Non-guest load on the dev host was not recorded. tests: a guest runs only where the host has a CPU for each of its vCPUs #1166 itself says its budget does not cover it.
- This sentence is what separates the sighting from host noise, so it must be accurate.
- Fix: write "it did not wait for host CPUs; host load was not recorded" and link tests: a guest runs only where the host has a CPU for each of its vCPUs #1166's evidence directory.
Commit message, metal-job-reboot-drained-… close reason. "Its rerun was green in 2 s" leaves out part of the deleted record: the second sighting was "red again alone", and main was red in 2 of 5 interleaved rounds. Every one of those runs was still beside other worktrees' load (load average 21 to 22, a concurrent DNS build), so the close itself stands. Per issues/README.md, the commit message is the close's evidence. It should say "red on main and branch alike, every run beside other worktrees' load" rather than cite one green rerun.

Suggestions

Commit message, the-console-loses-typed-keystrokes…: tests: session_lifecycle types each key once the panel shows the last #1169 is still open and paces session_lifecycle, not this test. Cite the surviving record, issues/a-command-typed-through-qmp-arrives-truncated-under-host-load.md, as where the mechanism is tracked.
issues/two-amdvi-boots-in-a-kvm-suite-wrote-not-one-byte.md:15: the edited line runs well past the paragraph's wrap.

Evidence

No build is needed for these records-only edits plus a /// line. The claims above were checked as follows:

landing order via git rev-list --first-parent origin/main;
git show ad6dc0781 / 520c0d129 / 99ee9625d;
git grep of every slug at ab2d8ce3c and at origin/main;
kernel/src/loader/mod.rs at 8261079e3 against main;
issues/the-kernel-still-creates-threads.md K4;
tests: a guest runs only where the host has a CPU for each of its vCPUs #1166's body and tests: session_lifecycle types each key once the panel shows the last #1169's state.

SEND BACK

Intermittent records that name a deleted test are gone through. Eleven of them were seen only on a loaded host and have no defect a remaining test can reach. They are closed, each for this reason: - a-netcase-boot-under-host-load-said-nothing-past-the-firmwares-screen-clears: netstack_socket_churn is gone. A boot that fell silent under load, with no mechanism found. - a-shared-boot-stopped-answering-and-no-capture-says-why: port_poll_churn and the 12-wide TCG shared tier are gone, and the stop was never seen again. - consent-prompts-click-on-an-open-launchers-row-made-no-launch: consent_prompt is gone. Seen once, at host load 34 to 47. - consent-prompts-skip-lost-its-prompt-and-the-hostile-window-at-host-load-100: consent_prompt is gone. Seen once, at host load 100. - log-reserve-window-negative-times-out-beside-other-guests: the test is gone. A boot timeout beside other guests. - metal-job-reboot-drained-no-kernel-output-beside-other-guests: the test is gone. Red on main and branch alike, every run beside other worktrees' load. - smp-ap-hole-and-log-reserve-window-red-under-a-loaded-host: both tests are gone. One WouldBlock while two other suites shared the host. - stdio-buffering-saw-one-long-line-arrive-as-two: 90_stdio_buffering is gone. One split line beside other guests. - syscall-window-nmi-shortfalls-on-a-contended-host: syscall_window_nmi is gone. A sampling shortfall on a contended host. - the-console-loses-typed-keystrokes-under-host-load: screen_console_scroll is gone. Its mechanism, keys typed through QMP lost under host load, is tracked in a-command-typed-through-qmp-arrives-truncated-under-host-load. - a-syscall-panic-reset-the-guest-announced-and-qemu-never-saw: syscall_panic_halts is gone with the reset_now path it drove. Red once, at a 2.96x liveness width on a loaded host, and nothing measured reproduces it. Metal has no QEMU SHUTDOWN event, so no planned test could retire it. Records that cited these files now carry what they took from them: parallel-tests-red-under-other-suites, guest-tests-a-loaded-host-can-turn-red, two-amdvi-boots-in-a-kvm-suite-wrote-not-one-byte, two-processes-started-at-an-entry-point-nothing-had-mapped (with the commits that deleted log_reserve_window), and one doc line in tests/toyos.rs. Records of real defects that no remaining test reaches stay open, and say which commit deleted their test: so-cache-refusals-saw-the-kernel-refuse- nothing-once (4505f87) and a-double-panic-at-boots-edge-says-nothing-but- its-name (ad6dc07). The double panic's owner is whoever holds the K4 stage of the-kernel-still-creates-threads, open as #1165, and its reproduction recipe goes with its test. a-holders-queued-line-can-reach-the-console-after-the-last-word cites that stage by path, quotes what it states and names that track's holder as owner. libc-childrens-tty-interrupt-can-stall-at-the-nested-shells-line gains its 2026-11-04 sighting at the nightly's shape, with #1166's evidence. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Japabu · 2026-11-04T10:15:09Z

Orchestrator verification of ab2d8ce3c..3443fe1ce. It touches records only: four files modified and one deleted under issues/, plus the commit message. No code changed.

The double-panic record names ad6dc0781 as the deleting commit.
The double-panic record's owner is the holder of the K4 stage in issues/the-kernel-still-creates-threads.md, and the stale recipe is gone.
The holders'-queued-line record cites that file's K4 by path, names kernel: no kernel thread but the idle loop; the console UART is a userland driver's (K4, K6) #1165 as its open PR, and takes the same owner.
a-syscall-panic-reset… is closed, and the commit message gives the reason (one red on a loaded host, the path is gone, nothing reproduces it).
The libc_children sighting reads "it did not wait for host CPUs; host load was not recorded" and links tests: a guest runs only where the host has a CPU for each of its vCPUs #1166's evidence.
The metal-job-reboot close reason reads "red on main and branch alike, every run beside other worktrees' load".

The suggestions were taken, including the amdvi line wrap. Every r0 blocker is resolved.

…rland driver's The small-kernel track's K4 and K6, by the owner's ruling that the kernel creates no thread but each CPU's idle loop. `klogd`, the one kernel thread, was the console's writer. It is gone, and so is every provision kernel threads had: `sched/kthread.rs` and its row table, `is_kernel_task` and `current_is_kernel_thread`, quiesce's exemption, the scheduler's zero baseline, `kernel_start`, `Start::Kernel`, a kernel stack without a user area, `Runs::Kernel`, the kernel address space object with its reserved PCID and ASID, `ElfInfo::none` and an `Option` on every task's image. The console UART - The kernel writes the UART only where no process can: inline as each record commits until `log::console::hand_over`, before userland runs; from the machine's stop, once userland is stopped; and on every fatal path. - Between them it is `/system/bin/uart`'s, which holds a `uart` claim (a new device class: COM1's ports and IRQ 4 on x86, as an `isa` row; the SPCR's PL011 frame and its level SPI on AArch64, which needed SPI routing to a row) and carries the log `logkeeper` feeds it on `log-wire`, as the virtio console's driver carries it on `log-carrier`: one carrier serving in logkeeper, two channels. The UART is quiet while the port carries, says so on itself, and is fed again when the port goes, stalls or the machine stops. - The kernel and logkeeper share one word: the newest stamp the console has spoken (`SYS_LOG_SPOKEN`, which replaces `SYS_CONSOLE_CARRIED`). The inline drain sets it; logkeeper advances it as a channel delivers whole rounds. The UART's driver starts after it, so the UART carries the boot once; the stop and a fatal path put every record after it on the UART. - The kernel's console object is gone with its queue: the supervisor makes the console's input a pipe, whose read end is every program's stdin and whose write end the UART's driver writes what the UART receives into. Its read waits on the pipe's readiness, not a 10 ms repoll. - Without a thread to post it, the log's readiness is owed by `emit` and posted at the next syscall's end or scheduler pass. Thread lifecycle - `SYS_YIELD`, and std's `yield_now` on it. - A detached thread's place goes as it ends (`proclife::leave_detached`), and `SYS_THREAD_EXIT`'s detached form releases its stack once the thread no longer runs on it; std's and libc's `REAPED` lists are gone. Deleted with the thread: `log/handoff.rs`, `kernel::carrier`, the sleep lock (its one user was `klogd`), the wire-holding actuators and their tests, the loom models of the handoff, the log waiter and the sleep lock, and their negative controls. Rebased onto main 2c2f957: #1171 added an owner and a citation of K4 (this change, then #1165) to issues/a-holders-queued-line-can-reach-the-console-after-the-last-word.md, which this change deletes. The record stays deleted: the kernel's holders' queue and klogd's drain it describes are gone, so no holder's queued line exists to follow the last word; the residual it named, a holder the stop did not stop, is the stop's shortfall, which its record reports by name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Japabu force-pushed the records-1b branch from ab2d8ce to 3443fe1 Compare November 4, 2026 10:00

Japabu marked this pull request as ready for review November 4, 2026 10:15

Japabu added this pull request to the merge queue Nov 4, 2026

Merged via the queue into main with commit ecdb6e6 Nov 4, 2026
10 checks passed

Japabu deleted the records-1b branch November 4, 2026 10:30

This was referenced Nov 4, 2026

kernel: no kernel thread but the idle loop; the console UART is a userland driver's (K4, K6) #1175

Merged

issues: an optional severity field flags dangerous defects for one query #1174

Merged

Navigation Menu

Repository navigation

issues: close the load-only records whose tests are deleted - #1171

issues: close the load-only records whose tests are deleted#1171
Japabu merged 1 commit into
mainfrom
records-1b

Japabu commented Nov 4, 2026 •

edited

Loading

Uh oh!

Japabu commented Nov 4, 2026

Uh oh!

Japabu commented Nov 4, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

Japabu commented Nov 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Change

Checks

Uh oh!

Japabu commented Nov 4, 2026

Review of #1171 at ab2d8ce3c

Blockers

Suggestions

Evidence

Uh oh!

Japabu commented Nov 4, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Japabu commented Nov 4, 2026 •

edited

Loading

Review of #1171 at `ab2d8ce3c`