The machine stops before Rebooting. claims anything about it

[Japabu]

quiesce disarmed the watchdog, synced every filesystem and wrote the boot's
last word while every other CPU was still running userland. Both of those are
claims about a machine and they were true only of the instant that made them.
On every T14 readback of tests/metalcase this repository holds, sshd —
spinning in Ring 3 retrying a netd that has no NIC on that machine — wrote its
own exit: record after Rebooting.:

readback	Rebooting.	exit: sshd	gap	stick_secs
metalcase (2026-09-07)	6.903 cpu4	7.033 cpu1	130 ms	0
run 34	6.101 cpu4	6.366 cpu1	265 ms	0
run 35	6.929 cpu4	7.035 cpu1	106 ms	0

bootlog::verdict is EXIT=1 for each.
issues/kernel/quiesce-runs-while-userland-still-does-io.md does not survive as
it was written — no process without the log capability runs across the sync any
more — but it is narrowed, not deleted:
issues/kernel/nothing-bounds-the-log-writer-below-the-boots-last-word.md is
what still stands once the general stop exists, under a slug that states it.

The boundary

kernel_exit_to_user_check is the one function every return to Ring 3 goes
through — the syscall gate, every device interrupt, the timer, the TLB IPI, the
trap epilogue and a task's first dispatch. A thread standing there holds no
kernel lock, has nothing in the block layer and nothing in flight on any
controller. Every record this kernel writes with a userland author is written
from inside a syscall, and a thread that never takes another userland
instruction never enters another syscall — so the stop is taken there, at the
same boundary a killed thread's last exit is taken at.

One rank, applied at two sites, with a test on each. A thread can stand at
that boundary carrying both marks. TaskShared::at_safe_point is the
declaration — written beside STOP and KILL themselves — and
scheduler::leave_ring3_if_due is one call and one match over it.
CpuSched::place applies the same rank to a task that is not running and reads
the two words itself, because the RT forward sits between the two arms. Both
are covered: stopping_outranks_killing_at_a_safe_point reds on the
declaration, stopping_outranks_killing on place's own order.

Tasks stop; CPUs do not

Every CPU keeps IF set, keeps taking its LAPIC timer and every device
interrupt and keeps taking passes — it has no userland left to dispatch. That is
what the USB stop below the last word needs and what klogd and iod need to
carry the log to its volume.

The carve-out is a capability, and the pid that was here is gone

wait_for_durable waits on one word, log::user::durable_ns, and that word
moves in exactly one place: a caller's clamped claim inside publish_durable,
reached only through SYS_LOG_READ. An earlier head took the carve-out's name
from there too — the pid that last advanced the word — and that was a defect.
A pid a caller nominates for itself through a syscall word is pid-as-authority,
self-claimed and refused by no name. Any holder of Rights::LOG writes
cursor.durable, so a second logread holder could take the carve-out off
logd; stage one would then band logd and the wait that carve-out exists for
could not be satisfied.

The tension that put it there, stated rather than rediscovered. The first
implementation carved out the capability — every caller that passed
demand_syscap(_, Rights::LOG) — and it was refused twice, on two different
grounds. Mechanically: the set was a Lock<Vec<u32>>, unbounded, sized from
userland by a holder with dup, never pruned, behind a machine-wide lock taken
on every SYS_LOG_READ — a syscall logd polls for the life of the boot. By
width: ten committed configs grant logread to two programs

for f in $(git grep -l logread -- '*/system.toml' 'system.toml'); do
  grep -c 'syscap = \[.*logread' $f; done | grep -c '^2$'
10

and a holder joins the carve-out at its first SYS_LOG_READ. On
tests/testcases the second holder is test-runner, which reads inside its
log-gate and log-close builtins and writes files and spawns across the
sync_all the stop is taken before. On tests/metalcase test-runner holds
the right and its committed config gives it no job list — the image staged for
the T14 gives it the reboot builtin alone, which reads nothing — so it never
reads and stops in the first stage; the carve-out there is logd alone. The pid answered both objections at once —
one process, one word, no lock — and paid for it with the caller's word.

Both are answerable without paying that. The identity is the capability again,
so nothing a process says about itself joins it. The mechanical objections are
answered where they were made: LOG_HOLDERS is a fixed array of atomics — the
shape kernel/src/sched/kthread.rs's ROWS already uses to answer the same
kind of question about kernel threads — so there is no allocation, no lock, and
it is readable with preemption off inside the block layer; and a surplus holder
is refused by name and stops in the first stage like any other. A slot is never
given back: no pid is issued twice, so a dead holder's slot names nothing that
runs. An earlier head released slots at teardown, for a reason that was false of
this kernel — a dup records nothing, a holder is recorded at its first read, and
the tree's readers are logd, console, test-runner and quiesce_twice —
and with no judge (the round-7 reviewer compiled the call out and the whole Fast
tier stayed green for it); the function and its call are deleted.
SYS_LOG_READ takes no lock of the carve-out's, as on main, and in the steady
state — logd finding itself in slot 0 — it is one relaxed load and no
read-modify-write.

An empty slot is u32::MAX, not zero. Zero is /system/bin/init's pid: the
process table issues from zero and init holds Rights::LOG, so with zero as the
sentinel holds_the_log(0) was false by construction and note_log_holder(0) a
silent no-op. u32::MAX is the pid percpu cannot represent, because it spells
idle with it; both functions refuse it by name, and quiesce's caller pair
starts there too.

The width is what is left, and it is tracked rather than claimed away. It is
narrower than main, where every process runs across the sync, and wider than
the wait, which depends on one. The exit condition is in
issues/kernel/nothing-bounds-the-log-writer-below-the-boots-last-word.md: a
right of its own, moved in by init from a system.toml row naming the program
that writes /log, so the kernel still reads a capability and not a claim. That
is an ABI change and lands on its own pull request.

One check-then-act, tracked. block::counted() reads holder status when an
operation opens, and a process becomes a holder at its first SYS_LOG_READ from
any thread. A sibling's first read while this thread is inside a counted
operation at the instant the first stage's record is taken leaves in_flight = 1 on an N of N record — a false red, never a false green. A multi-threaded
holder is not hypothetical: test-runner on tests/testcases is one. What no
committed config arranges is its first read landing beside a sibling's
operation as the stop ends.
issues/kernel/the-stops-in-flight-count-decides-who-is-counted-at-the-open.md
carries it with its exit condition.

One shutdown, claimed by name, and judged

CALLER_PID/CALLER_TID are one global pair, and a second SYS_REBOOT or
SYS_SHUTDOWN caller overwrote the identity the first is exempt by. The first
caller can be parked — block::between_attempts parks inside the retry loop
writeback::drain_all runs — so a second caller's sweep bands the thread with
the rest of the shutdown to perform. quiesce::claim_the_shutdown is one
exchange (kernel/src/quiesce/claim.rs) taken before the watchdog is disarmed;
the loser is refused by name and gets AlreadyExists back through Ring 3.

That guard had no judge, and now has one. tests/quiescetwicecase runs
quiesce_twice. Its child closes a 64 KiB file on /log and asks for the
reset. writeback-stall parks iod, so that file's flush is the shutdown's own
drain's to find; the new quiesce-drain-refuse actuator refuses its FAT-1
mirror write eight times as a budget expiry on the thread running the shutdown,
so that thread parks in block::between_attempts for 10, 20, 40, 80, 160, 320
and 640 ms between its attempts. The job itself — a holder of the log
capability, so still running in the stop's first stage — reads the kernel's log
until the first refusal is in it and asks again from the other CPU, through
SYS_SHUTDOWN: the first seat is SYS_REBOOT, so the one boot judges the claim
on both power syscalls.
quiesce_refuses_a_second_shutdown judges where the kernel's refusal lands:

  [power] the second caller was refused at console line 225 while the first was in its ladder (refusals at lines 221 to 236):
    [kernel 0.442 cpu0] log-volume: quiesce-drain-refuse: refusing the shutdown drain's FAT-1 mirror write as a budget expiry, 1 of 8
    [kernel 0.442 cpu1] power: this machine is already stopping, so this caller stops with the rest

It asserts, in order: one Syncing filesystems... on the boot; eight actuator
refusals, the kernel's own count; the refusal by name once, between the first
and the last of them; the second caller's AlreadyExists reaching its console;
Rebooting.; and QEMU's guest-reset.

With the guard deleted it is red, in two shapes, and neither is "no
Rebooting.". The prediction was that the banded first caller leaves the
machine with no last word. What the machine does instead is run a second
shutdown — on every one of the sixteen further boots that kernel was given at
40573079 (eight runs, each booted beside and then alone, EXIT=1 on all
eight; the round-7 reviewer added twenty, 38 of 38 with the handoff's). In ten
of the sixteen the second caller finds the first parked, bands it, and performs
the whole shutdown itself: two Syncing filesystems... on two CPUs — 1 ms apart
on eight of the ten, 2 ms and 11 ms on the other two — one stop: record and
one Rebooting., both the second caller's. In six it finds the first still
running between attempts and the two interleave:

[kernel 0.466 cpu0] stop: 3 of 3 userland thread(s) stopped across 2 cpu(s) in 0 ms over 1 sweep(s), 0 of 2120 userland block operation(s) still open
[kernel 0.466 cpu0] Rebooting.
[kernel 2.449 cpu1] Syncing filesystems...
[kernel 2.449 cpu1] stop: 3 of 4 userland thread(s) stopped across 2 cpu(s) in 2012 ms over 202 sweep(s), 0 of 2692 userland block operation(s) still open; this reset lands wherever the other 1 are
[kernel 2.449 cpu1] Rebooting.

— the second caller's stop spends its whole budget on the one thread that will
never reach a safe point, and then writes a sync line and a second last word
under the boot's last word. Both shapes write the sync line twice, which is
why that count is the judge's first assertion.

The stop leaves no filesystem update half made, and the volume checker says so

stop_if_blocked marks any parked thread, and block::between_attempts parks a
thread between two attempts of one filesystem update. A banded thread never
finishes its syscall, so what a refused attempt left on the volume stays there
at the reset. The round-7 reviewer named that as a hypothesis;
quiesce_leaves_the_volume_whole is the run.

quiesce-fsync-refuse, a third actuator of fat-mirror-write-refuse's shape,
refuses the active FAT's write in nine attempts of a SYS_FSYNC flush from
the moment the machine is stopping — after set_fat_entry has written the
mirror, which is the order that function keeps. The caller is logd. Its
ladder's parks (10 ms doubling, 2550 ms over nine refusals) outlast
log::SHUTDOWN_DURABLE, and a const assertion holds that; so the shutdown gives
up waiting for /log and the stop's second stage meets logd parked over
two FATs that disagree. The second stage and not the first, on purpose: /log
has 512-byte clusters, so in the first stage logd itself allocates the split
cluster within a few records and heals it by accident; below the second stage
nothing in the machine allocates again.

On the kernel without the fix — BUILD EXIT=0, TEST EXIT=1, the same
failure both times, from toyos-fat32-check:

FAIL quiesce_leaves_the_volume_whole: the machine's stop left the log volume breaking the format:
FAT 1 differs from FAT 0 at entry 44: 0x0FFFFFFF against 0x00000000. BPB_ExtFlags has mirroring on, so every copy must carry every update

The fix is the unit. The count the stop already keeps is per block
operation; what may not be cut is the filesystem's update. toyos_sched::task
carries MID_UPDATE in the task's state word, so stop_if_blocked refuses a
task parked inside an update in the same exchange that reads Blocked — a
flag beside the word would be a read and a mark that can come apart.
block::begin_update is the guard and ops::fsync holds it across its ladder,
the one retry ladder a userland thread can be parked in. The sweep counts such a
thread as running, so the stop waits for it inside PARK, bands it at the Ring 3
return of that same fsync, and says so in the record's shortfall clause if the
update outlasts the budget. With it — BUILD EXIT=0, TEST EXIT=0:

  [fat] the stop's second stage met a flush parked over split FATs and let it close; the checker is silent:
    [kernel 2.438 cpu0] shutdown: /log did not answer in 2000ms, so this shutdown's last lines are on the console only
    [kernel 3.006 cpu0] fsync: /log/2026-09-18-151803.log durable on attempt 10 after 2567ms — a refused attempt kept every page dirty and a later one delivered them

The judge asserts the harm first (the checker, over a partition asserted clean
before the boot), then that the arm fired nine times, that the shutdown gave up
inside that ladder, and that the flush closed after it — a whole volume that
does not say so was healed by something else, and is a red.

What it costs, said rather than hidden: that fsync: line is a kernel
record under the boot's last word, on a boot whose shutdown has already said its
last lines are on the console only.
issues/kernel/nothing-bounds-the-log-writer-below-the-boots-last-word.md
carries it as what is still owed.

Read on the way, filed, and not fixed — it is main's and unmeasured:
toyos-fat32's append_cluster claims the new cluster and then links it, and a
refusal of the link leaves that cluster allocated where rollback_to — which
walks the chain from the file's head — never reaches it, so the caller's retry
allocates another. That is a leak a successful retry does not heal, and it is
the sentence log_flush_retry and fat_backing_revoked say in
issues/build/a-loaded-suite-reds-a-volume-checker-on-both-arms.md;
issues/filesystem/a-refused-link-write-leaks-the-cluster-append-cluster-just-claimed.md
names the host test that would show it. It is also why the actuator's first
refusal in an attempt is always the allocation's active-FAT write, which ends
the attempt: that is the one split set_fat_entry's order makes a retry heal.

The record, and the one counter behind it

stop: 9 of 9 userland thread(s) stopped across 2 cpu(s) in 30 ms over 4 sweep(s), 0 of 17401 userland block operation(s) still open

toyos-quiesce renders it and parses it and nothing else spells it: the kernel
writes it, src/metal.rs reads a Record off a stick and
tests/common/power.rs reads one off a console.
every_record_reads_back_as_itself_off_a_line_of_log is what a reworded
Display arm fails.

The stage split is gone. An earlier head kept two open-operation counters so
the second stage's record could carry the carve-out's own operations — and that
second term had no control that it ever counted. It is deleted rather than given
a judge, and Stage::covers, Stage::stopping, open_count and the guard's
stopped_by: Option<Stage> went with it. One counter answers the question: an
operation is counted iff the stop's first stage stops the thread that opened it,
decided at the open and carried on the guard as a bool. The second stage's
record prints the same word and the harness no longer asserts on it there: a
thread holding such an operation is inside a device with preemption off, which
the sweep counts as running, so that clause could never have fired before the
one above it.

The ceiling of 0 is a claim about a stopped machine, and it holds because no
open operation can outlive its opener's stop. Lock::lock disables preemption
and the guard re-enables it on drop, and every begin_operation in the NVMe and
USB-storage paths sits inside a BlockDevice method reached only through
Partition::read_blocks/write_blocks/flush — under that guard, on the
opener's own thread, with no park anywhere in those wait paths. The one
begin_operation that is not inside a BlockDevice call is in
kernel/src/drivers/xhci/mod.rs's flush_disks: it runs on the reboot caller's
own thread and closes before either record is read, so it is outside both counts
by the time they are taken.

The two checks this change is judged by

Every mutation's build exit is given before its test exit — a mutation is a
measurement only once the mutated tree is shown to build. BUILD is
cargo test --test toyos-build -- --jobs 1 process_stats, which builds the
toolchain, the kernel, every guest binary and the image and then boots one
unrelated test; TEST is the same runner on the judge named. Measured on
this head's tree, each restored from the index under a trap with the working
tree read back equal to it: the whole-change control, the whole of the
update-unit fix reverted, the holder call never taken, the guard deleted, and
the guard moved into one syscall. Measured at 40573079 by the implementer
and again by the round-7 reviewer, and not re-run here: the two one-field
mutations of the block layer's count and the three-writer guest; nothing this
head changes is on their path.

The negative control: the whole change reverted onto the base, judges kept.
git restore --source=origin/main --worktree -- kernel/ toyos-sched/, with
origin/main at 9f91b581, puts the base's mechanism — 21 files — under this
branch's instruments; every judge, guest binary, boot config and profile row
stays the branch's (0 files differing under tests src toyos-quiesce issues).
kernel/src/quiesce.rs survives as a file the base's main.rs declares no
module for, so it is not compiled. BUILD EXIT=0, TEST
quiesce_stops_the_machine EXIT=1, red on the defect itself both times:

FAIL quiesce_stops_the_machine: 5 line(s) reached the console after the boot's last word:
  quiesce-writer: 5 2
  quiesce-writer: 4 2
  quiesce-writer: 0 5
  quiesce-writer: 3 4
  quiesce-writer: 2 5

The update-unit fix, reverted whole — MID_UPDATE out of the state word,
block::OpenUpdate gone, ops::fsync holding nothing, three files — BUILD
EXIT=0, TEST quiesce_leaves_the_volume_whole EXIT=1, the same failure
both times, quoted in the section above. Its independent oracle is
toyos-fat32-check, written from Microsoft's fatgen103 and sharing no code with
the driver it judges.

The independent oracle is the block layer's own count, which the stop does
not produce: it is incremented where an operation opens, in a driver leaf, and
the stop is judged against it. Both of its one-field mutations are seen.

Deleting the fetch_add alone, the guard still decrementing — BUILD EXIT=0,
TEST EXIT=1:

FAIL quiesce_stops_the_machine: the block layer still had 4294955142 operation(s) open on a thread this stop had stopped
  stop: 9 of 9 ... 4294955142 of 12154 userland block operation(s) still open

Making both ends agree that nothing is counted
(counted() && core::hint::black_box(false)) — BUILD EXIT=0, TEST
EXIT=1:

FAIL quiesce_stops_the_machine: this boot began no block-device operation on a stoppable thread, so the zero above is a counter that never counted
  stop: 9 of 9 ... 0 of 0 userland block operation(s) still open

The carve-out is load-bearing, and its removal is seen too — in the form that
builds. Deleting the one call that records a holder does not build: the kernel
denies note_log_holder and REFUSED_A_HOLDER as dead code, so that mutation
measures nothing. The call compiled and never taken
(if core::hint::black_box(false) { note_log_holder(..) }) — the capability
still checked, no holder ever recorded — bands logd in the first stage, so the
durability wait can never be satisfied. BUILD EXIT=0, TEST EXIT=1, the
same failure both times:

FAIL quiesce_stops_the_machine: 1 line(s) reached the console after the boot's last word:
  [kernel 2.906 cpu1] shutdown: /log did not answer in 2000ms, so this shutdown's last lines are on the console only

The one-shutdown guard, whole and in both partial forms. The call, the
refusal, claim_the_shutdown, its static and its module deleted — BUILD
EXIT=0, TEST quiesce_refuses_a_second_shutdown EXIT=1, the same
failure both times:

FAIL quiesce_refuses_a_second_shutdown: this boot ran 2 shutdowns, not one: the second caller was let in
  [kernel 0.425 cpu0] Syncing filesystems...
  [kernel 2.438 cpu1] Syncing filesystems...

The claim moved out of quiesce() into sys_reboot alone used to pass,
because both callers used SYS_REBOOT. The second caller now asks through
SYS_SHUTDOWN, and that mutation is BUILD EXIT=0, TEST EXIT=1, the same
sentence both times. The judge counts the shutdowns before it asks how the
machine ended: the first run of that mutation read QEMU stopped this guest for "guest-shutdown" alone on one of its two boots, which is the second caller
winning — true, and not the harm.

A load and then a store in place of the one exchange is reached by no boot:
the second caller arrives a millisecond after the first. It is
kernel-loom/tests/shutdown_claim.rs's, over kernel/src/quiesce/claim.rs
itself and not a transliteration: EXIT=0 as written, EXIT=101 under
--features shutdown-claim-split with two callers ran the shutdown, wired
into host-tests.yml beside the other model controls.

The workload judge fires on the partial fix that used to pass. It asked for
at least six threads and was met by three writers plus three others. It now asks
for exactly nine: six writers, init, and test-runner's main and deadline
threads. logd holds the log and the first stage's sweep passes over it
uncounted; the job's own main thread is the caller. Measured at 40573079, by
the implementer and again by the round-7 reviewer — the guest run with three
writers where the harness is told six, BUILD EXIT=0, TEST EXIT=1, stop named 6 ... make 9, the same failure both times. This head changes that
message's words and not its count.

The green arm was re-measured after the last restore: BUILD EXIT=0, all
three judges EXIT=0, with the record, the refusal and the closed flush
quoted above.

The second oracle is the machine: a T14 readback with Rebooting. last and the
stick enumerating 0 s after, which is owed and named below.

The guest says when it is ready; the harness counts what the kernel stopped

quiesce_writers puts six threads into a write-and-fsync loop and asks for the
reset only once every one of them has completed a pass. The harness judges the
kernel's own thread count, which the guest cannot write, and judges it exactly:
a writer whose loop ends on an I/O error now says which call failed, and leaves
eight where nine are asked for.

Gates, each with the exit status of the command itself

All on this head's tree, 2026-09-21.

command	result
cargo test --test toyos-build (the harness's whole Fast tier)	346 passed, 1 failed, 347 total, 102 held back for the nightly, 412.3 s, EXIT=1
cargo test --lib	307 passed, 1 failed, 1 ignored, EXIT=101
cargo test --workspace --exclude toyos-build	142 test result: ok lines, 0 failed, EXIT=0
toyos-sched alone	74 unit tests passed, the new a_task_parked_mid_update_refuses_the_parked_mark among them, EXIT=0
kernel-loom shutdown_claim / the same under --features shutdown-claim-split	EXIT=0 / EXIT=101
the host job's five cargo clippy invocations, spelled as src/clippy.rs spells them	EXIT=0 on each
the three quiesce judges after the last mutation's restore	EXIT=0 on each

cargo test --lib's red is main's, and it is a date.
redlist::tests::every_row_can_say_what_it_claims refuses four rows measured on
2026-08-20 and 2026-08-21 as more than 31 days ago, and still standing
(console_line_atomicity, kill_while_blocked twice, xhci_full_speed_device).
This branch does not touch src/redlist.rs (git diff origin/main -- src/redlist.rs is empty), so origin/main at 9f91b581 reds the same way
today, and a plain cargo test stops at that target before it boots a guest —
which is why the tier above is run by its own target. The rows are their
owners' to re-take, retire or delete; nothing here ages them away.

The tier's one red is not shown to be this diff's, and it is not on the
list. handle_kill_policy: 16 more killed processes left more live objects behind: [("SharedMem", 5, 6)], then ALONE handle_kill_policy: GREEN, in a
tier that took 412.3 s against the 147.3 s the same tier took at 40573079 —
another agent's work resumed on this host beside it, and the same boot shows
usb-storage: ... no answer in the data phase in 2000 ms. cargo run -- --known-red handle_kill_policy answers NOT KNOWN-RED: the redlist carries
this sentence (with Process where this one says SharedMem) as a loaded-host
sighting retired on 2026-09-04 by six green tiers. It is a machine-wide census
either side of a kill on a shared boot; nothing this branch changes allocates or
frees a SharedMem. One sighting prices nothing, and it is the redlist's to
re-open at its owner, not re-run away here. fs_dirs_durable, the tier's red at
40573079, was green in this run.

Two reds seen at earlier heads, named rather than re-run away.

• blocked_dump — the round-6 reviewer's tier run at c2352819 read PANIC: ... src/sched/dump.rs:134:5: the blocked-task dump ran under a lock: preempt depth 2, backtrace dump::request <- driver::drain_irqs <- driver::pass_block <- completion::wait_inner <- inbox::submit, green alone. It did not occur in
  this head's tier run. The path is main's: this branch's only change under
  kernel/src/sched/ is 14 lines in driver.rs, and completion.rs,
  dump.rs and inbox.rs are untouched. It is a kernel defect on a path this
  branch does not own and belongs to its owner in the redlist.
• guest (11), CI run 34896137159 at 8fdb28b9: FAIL metal_device_probe: usbwrite: the job refused — IoFailed, green alone. The diff does touch the
  guard every USB write opens (block::begin_operation) and the placement every
  wake crosses (CpuSched::place), so it was measured rather than read: a
  same-session A/B on metal_device_probe, three boots at 40573079 and three
  with the working tree set to origin/main at dc38a054 (0 files differing
  from it) — EXIT=0 on all three at head, EXIT=0 on all three on main.
  CI's own run at c2352819 (35100889732) concluded success with that shard
  in it. The round-6 reviewer found the line in one of the last 40 failed
  ci.yml runs and in no other; here it reproduced on neither arm. Six boots do
  not price a rate that small, so this says the diff is not shown to cause it,
  not that it cannot; it is the redlist's to carry at its owner.

The merge, and the numbers it had to choose between

origin/main at dc38a054 is merged in, 7 commits past the previous merge
base, with no conflict. The earlier merge of 45 commits at 8261079e had three
conflicted files, every hunk of both sides accounted for in that merge commit's
message, and one choice that still stands: boot.deadlinewedge.complete_ms,
.back_secs, .deadline_lateness_ms, boot.hardlockup.complete_ms and
.back_secs carry a measured both sides moved — main's from T14 run 44, this
branch's from run 46. measured is the last reading the machine gave, so run
46's stand; main's run-44 panel_max_us/panel_us on those same two boots are
untouched by this branch and stay. The run-56 staging below supersedes all of
them at once.

The machine

The four T14 boots are owed at this head, and the arms are the
orchestrator's. The run-55 images were staged at 40573079 and are stale: this
head changes the kernel every one of them carries (block.rs, object/ops.rs,
quiesce.rs and its new claim.rs, log/user.rs, process.rs,
fat32_adapter.rs) and the scheduler's state word. A run-55 reading still
describes this head in one respect only — the first stage's record on a boot
where nothing is parked in an fsync ladder takes the same path — and it does
not describe the second stage, which now waits such a ladder out. They are
restaged at target/metal-quiesce-run56/ from a tree clean before and after at
this head, with hashes, invocations and expected lines in
t14-request-quiesce-6.txt. Each of the four carries the stop record's literal
once; an image from a worktree without this branch carries it zero times and
Rebooting. once, which is what says the reader works.

What this costs, declared

tests/metal-profile.toml gains 15 rows — park_open_operations for each of
the 15 boots that reset through quiesce. park_ms is priced nowhere and that
is the point: a stop that gives up spends its budget and no more, so a ceiling
on the duration could be exceeded only in the expiry case, which
Readback::stop_completed already reds on for every boot the suite reads back
by reading the record's own shortfall clause.

Three registered names. quiesce_stops_the_machine is priced: CI run
34896137159 measured it at 4,434 ms across twelve shards, inside
FAST_COMMIT_MS, so it stays Tier::Fast. quiesce_refuses_a_second_shutdown
is priced by CI run 35355556050 at 40573079, whose test-durations-merged
artifact reads 4,249 ms across twelve shards; that one row is taken from it
and no other, and it stays Tier::Fast. quiesce_leaves_the_volume_whole is
new and carries the UNMEASURED marker, so this landing pays the two CI cycles
a new name costs a second time; the dev host ran it in 4 s, most of it the
2,000 ms the shutdown waits for a /log the actuator keeps from answering.
quiesce_writers and quiesce_twice are guest binaries on RUST_SKIP and
carry no row. Two new actuators, quiesce-drain-refuse and
quiesce-fsync-refuse, each with a FLASHABLE ruling of Never, and one
kernel-loom control, shutdown-claim-split. quiesce::PARK says what it is —
a budget, not a bound the kernel can prove — and its expiry is a clause in the
record rather than a hang.

Decisions in toyos-quiesce/ (pure, 10 tests); effects in
kernel/src/quiesce.rs.

Filed and not fixed:
issues/build/two-worktrees-race-provisioning-the-toolchains-cargo.md,
issues/kernel/the-machine-stops-without-saying-which-thread-took-the-time.md,
issues/diagnostics/a-t14-wedge-ran-the-deadline-out-and-sealed-nothing.md,
issues/kernel/nothing-bounds-the-log-writer-below-the-boots-last-word.md,
issues/kernel/the-stops-in-flight-count-decides-who-is-counted-at-the-open.md,
and — in main's own code —
issues/kernel/the-shutdowns-drain-counts-the-queue-while-iod-holds-an-entry.md
(writeback::drain_retrying counts the queue without the VFS lock drain_one
pops under, so a shutdown can sync and reset while iod still owes a
budget-refused flush) and
issues/filesystem/a-refused-link-write-leaks-the-cluster-append-cluster-just-claimed.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK