The T14 profile goes from 30 boots to 27: the orderly-reboot rows ride metalcase, the self-tests arm shared-debug, and netstack's lease probe is deleted

[Japabu]

Step A of fewer, fuller boots on the T14: rows moved onto boots that already exist, and one boot deleted with the shipped code that existed only for it. No harness or runner code changes; userland/test-runner is untouched.

The owner's principle, verbatim: "we want as many test on the t14 as possible. its the only true tests we have. if the tests suck we delete them outright. tests that require their own boots must bring value."

Boot count

cargo test --test toyos-build -- --metal --list, as the harness prints it:

head	line
d83ab1398 (merge base)	[metal] 68 registration(s) and 229 shared member(s) over 30 boot(s)
c84f5fafe (the head run at; the commits after it change only files under issues/)	[metal] 67 registration(s) and 229 shared member(s) over 27 boot(s)

Lines: +236 −1281 over 28 files (git diff --shortstat origin/main...HEAD). Production code (netstack, toyos-i219 less its tests): +12 −638. Harness, tests, record and issues: the rest.

What changed, per decision

jobcase's rows ride metalcase. blackbox_done_chain, machine_reboot and the control arm of usb_reset_hands_devices_back read the loader's pass after the reset, the kernel's reset-register decode and the reset's own account, which every boot that hands the machine back writes. jobcase was its own boot by history: under QEMU the same rows boot tests/jobcase, whose committed job list is the one reboot; on the T14 every job list is derived and metalcase's is that same empty list. What a boot-mate's red now does: metalcase starts the compositor, soundserver, netstack and sshserver, so a stop that wedges on one of them reds these rows beside metal_sim_scanout_wc, where jobcase started none. (machine_soft_off_decoded, the fourth jobcase row, was deleted on main by #764.)

The lease probe is deleted, on the owner's ruling ("Yes, delete"): the lan_lease_report row, tests/lanleasecase, netstack's --exit-with-lease with its report file and window, toyos_i219::lease, toyos_i219::phy::Outcome, the gate in src/build.rs that held the flag to a card the Intel driver opens, Readback::log_volume_file, tests/common/volumes.rs, and the harness's dev-dependency on toyos-i219. lan_dhcp_lease on lantalkcase reads the lease off netstack's own lines. The driver's test of who stood beside another agent's flag asserts the refusal's own beside where it asserted an exit code. issues/netstacks-lease-probe-answers-a-question-its-lines-already-answer.md is closed by deletion; it carried no rule to fold to a site. The records that cited the probe are corrected, and the lan_hold issue is renamed, one boot being left with the sleep.

The init self-tests arm the SYS_DEBUG members' boot. selftests and shared-debug were the same kernel on the same config; shared-debug takes the eleven parameters and the ten rows name it. The owner's ruling: "Yes, after a trial". The trial is below, and the seventeen agree. What a boot-mate's red now means: the seven members run armed with the eleven self-tests on the T14 and unarmed under QEMU, so a member red on the T14 alone has the arming as a candidate cause, and a kernel death in a self-test at init reds the seven with the ten.

The ACPI server's two rows keep testcases-hold. They were moved onto testcases (9ded9075c) and moved back (c84f5fafe) after the T14 read the move red; both commits are in the branch. See the first T14 run.

Timing rows stay on testcases-debug: the owner's ruling, "Wait for step B".

The machine record loses the rows of the three labels that go (jobcase, lanleasecase, selftests).

The T14 runs

Images staged with --metal --metal-readback, booted by the orchestrator, judged by the harness's own offline judge.

run	head	boots (each rc=0)	judge
1	9ded9075c	metalcase, metaldevicecase, testcases, testcases-watchdog, selftests, shared-debug (unarmed)	EXIT=1: 43 passed, 1 failed
2	4b53cd888	shared-debug (armed with the eleven)	EXIT=0: 17 passed, 0 failed
3	c84f5fafe	testcases-hold	EXIT=0: 2 passed, 0 failed
4	c84f5fafe	testcases, testcases-watchdog (rc=0); lantalkcase (toyos-metal rc=1)	EXIT=1: 21 passed, 3 failed

Run 1's red: FAIL acpi_server_events: the server logged 1 first sighting(s) and None for counts, on testcases with test_rs_acpi_hold its last job. The server was not at fault. It writes its count thirty seconds after it arms (armed at 12.851 s on the log's clock, so about 42.9 s), and testcases logs about forty megabyte files under counters_metal's dump where logkeeper keeps sixteen and deletes the writing boot's own middle by design. The readback's last record before the hole is at 34.875 s and its first after it at 47.220 s; fifteen deletion lines survive in it, the first logkeeper: /log holds more than 16 logs, so /log/2026-10-08-140646_0012.log was deleted at 47.238 s, the earlier ones having gone with the parts that held them. cpu0's last census reads userdev=48, as on the quiet boot, so the server served throughout. On the quiet testcases-hold boot the line is there (run 3: PASS acpi_server_events, PASS acpi_tables_loaded, test_rs_acpi_hold exit 0). Filed as issues/a-t14-boot-that-outlogs-its-retention-loses-its-middle-and-the-rows-whose-lines-sat-there.md: the hole is in testcases' readback of 2026-10-07 as well, the harness says nothing of it, and step B's merged boot logs more.

Run 4: testcases at its nine-job list and testcases-watchdog, every row PASS (21). The three lantalkcase rows are red with one line each, the boot's refusal and not a row's own finding:

FAIL lantalkcase: toyos-metal refused lantalkcase: the boot did not say over its own cable what a talking boot owes:
FAIL lan_dhcp_lease: toyos-metal refused lantalkcase: the boot did not say over its own cable what a talking boot owes:
FAIL lan_message_delivery: toyos-metal refused lantalkcase: the boot did not say over its own cable what a talking boot owes:
FAIL lan_talk: toyos-metal refused lantalkcase: the boot did not say over its own cable what a talking boot owes:

verdict.txt reads refused … the stream never opened: the host did not reach the machine. That is the harness's rule and not this diff: read_readback (tests/common/metal.rs, unchanged here but for the deleted log_volume_file) answers a refused boot's readback with the refusal, and every row riding the boot takes it. main does the same for the same refusal: lantalkcase staged from 6f87cdb9c and booted the same day has the same verdict.txt (issues/lan-talk-is-unread-on-the-t14-since-the-claims-binding-landed.md). So no row read this head's netstack on the T14, and the lease probe's deletion is not shown on metal by a judge.

What the stick of run 4 carries, read by hand and not by a judge, beside the same lines of main's boot:

line on the stick	c84f5fafe	main 6f87cdb9c
pcidev: PCI 00:1f.6 [8086:15fc] handed over on slot 0, vector 0x28	present	present
pcidev: slot 0 took its first message on vector 0x28	present	present
netstack: I219: link up at 1000 Mb/s full duplex, … ms after the driver came up	2750 ms	2740 ms
netstack: DHCP: lease …, … ms after netstack came up	13306 ms	13298 ms
netstack: ready, at most 103 piped connections	present	present
a netstack exit or panic before the stop	none	—

lan_dhcp_lease is not a stick-only row: lan::on_metal holds the lease to the address the host reached the machine at (back.talk()), so it cannot pass while the cable path is down, whatever the harness did with a refused boot. lan_message_delivery is stick-only and is hidden by the refusal; filed as issues/a-cable-refusal-hides-the-stick-only-row-of-the-talking-boot.md, the rule unchanged here.

The seventeen (the trial of the self-test move): the seven members abuse_kernel_addr, counters_silent, handle_lifetime, ring0_timer_in_syscall, shm_release_reclaims, spawn_child_ends_first, spawn_lands_claimed exit 0 on the unarmed boot of run 1 and on the armed boot of run 2; the ten rows pci_capability_walk, read_fault_selftests, leak_rollback_selftest, lapic_spurious_vector, xhci_xecp_walk, xhci_descriptor_walk, sysret_ss_reload, input_merge, operation_nesting, iommu_firmware_left pass on selftests in run 1 and on shared-debug in run 2.

Which boots of this head were booted where

Of the boots whose membership or image this pull request changes:

boot at this head	booted at	what the later commits change of it
testcases-hold	c84f5fafe, this head	—
shared-debug, armed, with the ten self-test rows	4b53cd888	nothing: git diff --stat 4b53cd888 c84f5fafe is tests/toyos.rs (the two ACPI rows' arms), three rows of the machine record and one issue file
metalcase, metaldevicecase	9ded9075c	nothing: git diff --stat 9ded9075c c84f5fafe is the same three files, and in tests/toyos.rs only shared-debug's parameters and the ACPI rows' arms
testcases, testcases-watchdog	c84f5fafe (run 4)	—
lantalkcase	c84f5fafe (run 4), refused for the cable: booted, and no row judged	—

Every other boot is the merge base's. The commits after c84f5fafe change files under issues/ and no input of any image.

Every boot this head keeps, and what its own boot brings

boot	rows	what the boot brings
testcases	21 rows, 9 jobs	the base: the shipping kernel on tests/testcases
shared, shared-debug	62 members; 7 members and the ten self-test rows	the shipping kernel's members; a different kernel build (SYS_DEBUG)
windowscase	mask_windows	a different kernel build, and it measures
latencycase	tlb_shootdown_cost, latency_wake	measures timing; the runner holds the real-time band
logstallcase	soundserver_log_stall	another logkeeper, and audio
metalcase	4 rows	the compositor holds framebuffer, keyboard and mouse; ends in an orderly reset the rows read
metaldevicecase	usb_reset_hands_devices_back's first arm	megabytes to the stick before its reset
proctreecase	5 rows	the runner's own manifest row is the subject
acpicase	acpi_server_death	no acpiserver may hold the claim the job hands over
lantalkcase	3 rows	the cable, and a host that ends the boot
testcases-watchdog	loader_watchdog_arms, watchdog_fed	a loader parameter; its control is the unarmed testcases
testcases-deaf	dump_nmi_probe	a kernel parameter deafens a CPU
iommu-no-remap	claim_refused_without_remapping	a machine with no interrupt remapping
isa-withheld	2 rows	a kernel that leaves the i8042 alone
deadlinewedge, hardlockup, usbload, usbbreak, foreignrecord	one row each	the ending: a wedge, a locked CPU, a reset mid-transfer, a broken transport, a foreign record
testcases-hold	acpi_server_events, acpi_tables_loaded	a log that is whole: on testcases the line the first row reads is deleted. Waits on the issue filed above

Boots whose own boot brings no value and are not moved here, and what each waits for:

boot	why it is its own	waits for
shared-2, ccorpus, testcases-bounds	the runner's one 60 s bound over the whole list	step B: a bound per member
testcases-mkdir, testcases-readdir	each fills a machine-wide cap and leaves it	each test removing what it made
testcases-debug	tlb_shootdown_waits and trace_record_cost read a clock, and the harness runs a shared boot's members before its rows' jobs	step B, by the owner's ruling

No row is proposed for deletion: neither the machine record nor the tracker holds a red history for one. What the tracker does hold against the profile is issues/lan-hold-holds-a-boot-open-for-a-flat-twenty-seconds.md (a helper's flat sleep) and issues/the-t14s-record-keeps-three-rows-of-a-boot-nothing-stages.md.

Gates

At c84f5fafe: cargo metadata --locked 0; cargo test --test toyos-checks 0 (37 passed); cargo run -- --build-only 0 (ends Build finished.); --metal --list 0 (67 / 229 / 27).

At 4b53cd888, whose difference from this head is the three files named above: cargo test --lib testargs 0 (17 passed); cargo test --lib build:: 0 (40 passed); cargo test -p toyos-i219 0; cargo test --test toyos-checks 0; --build-only 0; and the harness's offline judge of the four metalcase rows over the T14's metalcase and metaldevicecase readbacks of 2026-10-07, 0 (made by a kernel older than #764: it shows the judges fit metalcase's bytes, and run 1 is what shows this kernel).

At 802287708, ci run 37793515070 (conclusion success): host ends [ci] Host: 78 step(s), all green; toolchain / build succeeded; guest / suite ends [ci] the suite: test result: ok. 36 passed, 36 total and [ci] Guest: 5 step(s), all green, netstack_socket_churn among its PASS lines. The tip after it changes one issue file.

No guest test is added, changed or cut. No dependency is added; one dev-dependency goes.

Unsure of

• issues/the-t14-stopped-answering-ssh-between-two-lan-boots.md: its exit named lanleasecase and lanswapcase. It now names lanswapcase alone, in the reviewer's wording; the owner has been told and may overrule it.
• Nothing on the T14 has judged this head's netstack in front of the I219. Run 4's stick shows, by hand-read lines only, that it brought the card up, took a lease, reached ready and stayed up until the stop; no connection was served on the T14. The owner's ruling on the talking rows, verbatim: "we should disable or remove those tests". A later pull request does that, and closes issues/a-cable-refusal-hides-the-stick-only-row-of-the-talking-boot.md in the same diff.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RvnWQFcMuGqTHYhvSnTe8A

[Japabu]

T14 run 4, at c84f5fafe (orchestrator): the two boots the body does not claim, and testcases-watchdog, which boot:testcases brings along.

boot	toyos-metal exit	image sha256
lantalkcase	1	f00f2e65…f135672
testcases	0	745a4a7b…c160d7
testcases-watchdog	0	c852b1c6…c31a38

Judge (--metal --metal-readback … boot:lantalkcase boot:testcases): EXIT=1, 21 passed, 3 failed, 3 boots.

• testcases and testcases-watchdog: every row PASS (21).
• lan_dhcp_lease, lan_message_delivery, lan_talk: FAIL, all three with toyos-metal refused lantalkcase: the boot did not say over its own cable what a talking boot owes. This is the bench's wired path, down on main as well and tracked in issues/lan-talk-is-unread-on-the-t14-since-the-claims-binding-landed.md; the three rows stay unread on the T14 at this head, and the lease probe's deletion is not shown on metal by them.

[Japabu]

Review of c84f5fafe against origin/main d83ab1398, round 1. Read only; nothing was built, run or booted. Read: git log origin/main..c84f5fafe (five commits), the whole diff, the changed files at the head, the body, the design note, and in the orchestrator's scratchpad builds/t14-fullerboots.log, builds/t14-fullerboots-h3.log, the three judge logs and the readbacks under fullerboots/metal-h1, -h2, -h3, and the gate logs under fullerboots/r3, r4.

Net: 27 files, +178 −1276 (git diff --shortstat origin/main...c84f5fafe). Production (netstack, toyos-i219 less its tests): +12 −638. Tests, harness, record, issues: +166 −638. Nothing grows; no deletion the branch could still make was found.

BLOCKER

• Evidence — no cargo run -- --ci host and no guest test at this head — run 37791997052 reports host, toolchain and guest all skipping (the pull request is a draft), and the body says none was run locally. netstack's main loop loses its probe arms inside the serving loop, and every guest test that boots netstack reaches it; clippy at CI's version over a tree that lost 638 production lines, the source and issue gates and every host suite but toyos-checks, testargs, build:: and toyos-i219 are unmeasured. Closes with no change to the branch when host, toolchain / build and guest / suite are green at the landing head.
• Evidence — the T14 has not read this head's netstack on the card it drives, in the body — the only production change is to the I219's server, and the body has no lantalkcase boot (it says so). Run 1 does not stand in for it: tests/metalcase/system.toml gives netstack a virtio id the T14 has not, so metalcase at 9ded9075c read a netstack that ends with no card (exit: netstack … code=0 at 12.5 s), not the Intel driver. Closes when the judge's own log at c84f5fafe over the two boots below is in the body; what each must show is under "The two boots owed".

NOTE

• issues/the-t14-stopped-answering-ssh-between-two-lan-boots.md:36-42 — the exit now says two things: :36-37 still gives this file lan_lease_report and asks three runs to "reach both judges, lanleasecase and lanswapcase", and :42 says the first is gone for good — an exit whose first half nothing can meet. One exit, in the owner's words; the body already says the wording is his, so it is asked before this lands, not after.
• tests/toyos.rs:1072-1077 with :2251 — the seven SYS_DEBUG members now run armed with eleven self-tests on the T14 and unarmed under QEMU. Accepted on the trial (seven exit 0 both ways, ten rows PASS both ways, one boot each). The body says what a boot-mate's red now does for the metalcase move and not for this one: a member red on the T14 alone now has the arming as a candidate cause. Prose, the body's.
• issues/a-t14-boot-that-outlogs-its-retention-loses-its-middle-and-the-rows-whose-lines-sat-there.md "Measured", and the body's run-1 paragraph — "no record between 34 s and 47 s": the saved log has 7098 records stamped in second 34; the last before the hole is at 34.875 s and the first after at 47.220 s. And fifteen deletion lines are what survived: the parts through _0026 all went, the earlier deletions' lines with them. Prose.
• PR body — the gates are commands and exits; their logs are on the orchestrator's disk and say what the table says (toyos-checks 37 passed, build:: 40 passed, testargs 17 passed, --build-only ends Build finished., --list at the head prints 67 / 229 / 27). Prose.

What the brief asked to be checked

• Which boots are this head's. As the body's table has it. git diff --stat 4b53cd888 c84f5fafe and 9ded9075c c84f5fafe are each tests/toyos.rs, the T14's record and the new issue file; in tests/toyos.rs the first touches only the two ACPI rows' arms, the second those and shared-debug's parameters. None is an input of the metalcase, metaldevicecase or armed shared-debug image, and no judge of their rows changed, so I take run 1's metalcase and metaldevicecase and run 2's shared-debug as this head's. testcases-hold is this head's outright (run 3, staged and judged at c84f5fafe). --list at base and head differ in exactly three lines: jobcase, lanleasecase, selftests gone; every other boot's job list is byte-equal, testcases' nine included.
• Same kernel for selftests and shared-debug. True: base SELFTESTS named no feature and tests/common/metal.rs:762-771 gives a boot whose parameters are not all declared ones TEST_KERNEL, which is what shared-debug names; both on tests/testcases. batches refuses arms that disagree on config, parameters or features, so the ten rows and the shared boot cannot drift apart silently.
• The rows' own boots. 21 boots in the first table and 6 in the second are the 27 --list prints. For the boots this diff touches the stated value is what the code says: metalcase starts the compositor on framebuffer, keyboard and mouse and runs no job; usb_reset_on_metal holds both arms to the same account and uses no contrast between them, so its second arm loses nothing on metalcase; testcases-hold is the one boot where the count line survives. The rest are main's registrations unchanged, read from their arms and not re-derived.
• Run 1's red. The saved testcases log shows what the body says, and one thing more exactly. acpiserver: armed at 12.851 s; first sighting of the query at 13.992 s; no count line. test_rs_counters_metal starts at 22.095 s and its dump begins at 34.4 s. Records stop at 34.875 s and resume at 47.220 s. The log keeper's own lines say the boot went from part _0026 to _0041 between 47.242 s and 54.123 s and deleted _0012 to _0026 in that span, the first at 47.238 s; the readback is the first part and the fifteen newest, sixteen in all, which is MAX_LOG_FILES and retire's rule (never the boot's first part, then its own continuations oldest first). Fifteen parts in 6.88 s is 0.46 s a part; the parts missing before _0027 at that rate are about 12 s, and the hole is 12.35 s. So retention accounts for the whole hole and nothing else is needed to explain it; the count line due at about 42.85 s is inside it. cpu0's last census reads userdev=48 there and on run 3's quiet boot, whose count line is at 42.851 s (26 SCIs … 0x4f x13). The issue's other two citations hold: the testcases-hold boot of 779330742 has its line at 42.579 s (28 SCIs … 0x4f x14, userdev=48), and the 2026-10-07 testcases readback has no record in seconds 36 to 47 and the same fifteen deletion lines.
• The new issue file. Frontmatter, slug and kind meet issues/README.md; owner named; the exit is one a harness red or a T14 row can fail. True of the tree and of the log, less the wording in the NOTE.
• The lease probe, nothing dead behind. Searched the tree at the head (git grep, the fork excluded): exit-with-lease, EXIT_WITH_LEASE, lease.txt, LANLEASECASE, leased_on_metal, log_volume_file, volumes::, read_files, toyos_i219::lease, phy::Outcome, from_exit_code, intel_driver, both deleted slugs: no hit. lanleasecase and lan_lease_report remain only in two issue files as history and in the exit above. What the deleted code alone used is gone with it: Change::lease, Nic::brought_up, brought_up_words' pub, the harness's dev-dependency and its lockfile line, the ALL_CONFIGS row. What stays has another reader: LEASE_BOUND_MS (dhcp.rs:37), bootlog::declares (src/lan.rs:197), Readback::exit_code (three callers), Speed::mbps, Counters, Wire, PhyRefusal's beside (its Display), fatfs (src/image.rs), tests/jobcase (five ending boots and the QEMU rows), READBACK_VOLUME (the outside judge's copy). The closed issue's own list of what would close it is met item by item, and it carried no rule to fold. No prompt names a removed boot or flag.
• The changed driver tests. the_refusal_names_each_agent_standing_beside_the_flag asserts the refusal's own beside per reading, so Others::in_reading answering a constant reds three of its four rows; the assertion dropped from an_interconnect_in_transition_… only restated the matches! above it through the deleted table.

The two boots owed

Both came back to the orchestrator's disk while this was being written (builds/t14-fullerboots-h4.log, fullerboots/metal-h4), unjudged and not in the body. What I read there is not the measurement; the judge's log in the body is.

• lantalkcase at c84f5fafe. On the stick: netstack opens the I219, says its bring-up sentences, the link line, a lease and netstack: ready, with no panic and no netstack exit before the stop. The saved log has all of it (link up at 1000 Mb/s full duplex 2750 ms after the driver came up, a lease 13306 ms after netstack came up, ready; no code=101). So lan_dhcp_lease, which reads only the stick, must PASS: a red there is this branch's and not the bench's. lan_talk may be red only as the stream never opened, which is what toyos-metal returned (rc=1) and what the tracked issue records of main. lan_message_delivery is not named by that issue: it passes, or its red is shown by the judge's own line to be the same host-side refusal.
• testcases at c84f5fafe, nine jobs. Every row on it PASS and the judge's exit 0. The saved log has the nine jobs each exit=0, reboot last, verdict passed. loader_watchdog_arms needs its other arm: testcases-watchdog was staged at this head and has no readback, so boot it or that row is unread in this judge.

SEND BACK

[Japabu]

Review of 802287708 against origin/main d83ab1398, round 2. Read only; nothing was built, run or booted. Read: git diff c84f5fafe 802287708 (two files under issues/, +58 −5, nothing else), the body, run 4's comment, ci run 37793515070's job logs, and on the orchestrator's disk fullerboots/metal-h4/judge.log, the lantalkcase readbacks of run 4 and of main's baseline, and tests/common/lan.rs and tests/common/metal.rs at the head and at origin/main.

Net: 28 files, +231 −1276 (git diff --shortstat origin/main...802287708). Production unchanged since round 1: +12 −638. The fix round is record only.

Round 1's BLOCKERs

• 1, no host and no guest run at the head — CLOSED. ci run 37793515070, event pull_request, headSha 802287708, conclusion success. host: the step cargo run -- --ci host succeeded and its log ends [ci] Host: 78 step(s), all green. toolchain / build: cargo run -- --ci toolchain and cargo run -- --ci bootstrap both succeeded. guest / suite: the x86_64 instrument line reads /dev/kvm opens; PASS netstack_socket_churn, PASS iommu_virtio_platform; the log ends [ci] the suite: test result: ok. 36 passed, 36 total and [ci] Guest: 5 step(s), all green. Nothing is left to wait for at this head. If the head moves for the edit named below, the merge queue's host and guest / suite must end in those same closing lines ([ci] Host: … all green; [ci] the suite: test result: ok. N passed, N total with netstack_socket_churn among the PASS lines) before it lands.
• 2, the T14 has not read this head's netstack on the card it drives — CLOSED, on a different measurement from the one round 1 named, because round 1 named one that cannot exist. Two things:
  • The disagreement: the implementer is right and round 1 was wrong. tests/common/lan.rs:57 (on_metal, the judge of lan_dhcp_lease) runs back.talk()? before it reads a line of the stick, and :108 holds the lease to heard.peer; Readback::talk (tests/common/metal.rs:287-298) is an error where the loop heard nothing. Both are main's, byte for byte (origin/main:tests/common/lan.rs:74 and :126); the diff's hunks in that file delete the lease probe's judge and constants and touch nothing in on_metal. So the row is not stick-only and cannot pass while the host does not reach the machine. Before that, read_readback (metal.rs:879-893) returns loop_verdict's refusal ahead of opening any log, so every row of a refused boot carries the refusal; this diff's only hunk in metal.rs deletes log_volume_file. main's baseline readback has the same verdict.txt (refused … the stream never opened). Round 1's "lan_dhcp_lease reads only the stick and must PASS" is withdrawn. lan_message_delivery is the stick-only one (delivered_on_metal reads back.kernel() alone), and the new issue file says so truly.
  • What stands for the hardware reading. The rule asks for the reading from that hardware, in the body. It is there: the stick of run 4 at c84f5fafe, beside main's of the same day. I read both readbacks and the body's table is theirs: the function handed over and its first message taken; link up 2750 ms after the driver came up (2740 on main); a lease 13306 ms after netstack came up (13298); netstack: ready; the hold job's exit … code=0 at 65.8 s and no exit: netstack and no panic line before it, on either. A lease is an exchange both ways through the card this change's server drives, so this is the card under this head's netstack and not only its register writes. The differential is main on the same machine the same day; the change is a deletion, and the two logs differ by 10 ms and 8 ms. A row's verdict over a talking boot cannot be had while the host cannot reach the machine running ToyOS, which is the owner's standing ruling and not this branch's; I do not hold a branch to a measurement nothing can make. The body's statement of what is not shown ("no row read this head's netstack on the T14", "not shown on metal by a judge", "by hand-read lines only") is true. It may land on this.
  • What would have kept it open, and would reopen it if found: an exit: netstack or a panic line on the stick before the stop, a missing link, lease or ready line, or either timing off main's by more than a boot's jitter. None is there.

Round 1's NOTEs

• issues/the-t14-stopped-answering-ssh-between-two-lan-boots.md:36-42 — OPEN, see below.
• The armed SYS_DEBUG members — CLOSED: the body now says a member red on the T14 alone has the arming as a candidate cause.
• The retention issue's "Measured" and the body's run-1 paragraph — CLOSED: both now give 34.875 s and 47.220 s, the parts _0026 to _0041, and that the fifteen deletion lines are the ones that survived.
• The gates' logs — CLOSED by the host run above, which runs them at the head.

BLOCKER

None.

NOTE

• issues/the-t14-stopped-answering-ssh-between-two-lan-boots.md:36-42 — the exit still gives this file a row and a boot that are gone for good, and contradicts itself three lines later — an exit whose first half nothing can meet. The issue's evidence is not ssh into ToyOS: both timeouts are toyos-metal's steps before a flash (reading the disk on the machine, `sudo -n` on the machine), spoken to the machine's other system, straight after the machine answered ssh again after 20 s; neither boot happened. The owner's answer is about a host that cannot reach the machine while it runs ToyOS, which is lan_talk's fault and tracked elsewhere; it does not describe this file and does not delete it. The one edit: make :36-42 one exit that names no deleted lease boot — lan_swap is owned by this file until it closes; three consecutive T14 metal runs each reach lanswapcase's judge without an ssh timeout before its flash; then the file is deleted — keep the sentence that lanswapcase waits on the restore issues/a-connect-between-two-accepts-is-reset.md records, and drop the sentence added at :42. Tell the owner his answer met a different fault.
• PR body, "Gates" — "Not run by this branch: cargo run -- --ci host and the guest suite" is now false of the record; the run above, with its closing lines, belongs there. Prose.
• PR body, "Unsure of" — "brought the card up, leased and served": no connection was served on the T14; netstack reached ready and stayed up until the stop. And "it closes when the bench's wired path is back and lantalkcase is read" is not the owner's ruling on those rows, which is that a later pull request disables or removes them. Prose.
• issues/a-cable-refusal-hides-the-stick-only-row-of-the-talking-boot.md — true of the tree and of both readbacks (the judge's line is judge.log:19; the two pcidev lines are on the stick); frontmatter, slug, owner and exit meet issues/README.md. Its exit asks for harness work on a row the owner has said goes; the pull request that removes the talking rows closes this file in the same diff. Prose.

LAND AFTER NAMED CHANGES