diff --git a/issues/build/a-metal-failure-drops-every-row-its-boot-measured.md b/issues/build/a-metal-failure-drops-every-row-its-boot-measured.md new file mode 100644 index 00000000000..0dabcc5249e --- /dev/null +++ b/issues/build/a-metal-failure-drops-every-row-its-boot-measured.md @@ -0,0 +1,23 @@ +--- +status: open +kind: tooling +opened: 2026-09-30 +--- + +# A metal failure drops every row its boot measured + +`tests/common/metal.rs`'s `judge_readbacks` puts boot labels in `failed`, and +`Readback::measured` records a number with no test attached. One red test or +shared member riding a boot therefore keeps every number that boot measured +out of the record, and a number never recorded is never judged. A runner that +carries every test in one session would drop every row of the session for one +red test. + +It already costs rows. On the T14's full run at `0d2dda66f`, `testcases`, +`shared`, `lancase` and `lantalkcase` each carried a known red, and +`tests/metal/lenovo-20w0003amz.toml` holds no row of theirs, so nothing +judges their numbers while those reds stand. + +## Exit condition + +Each number is recorded against its owner, and only that owner fails. diff --git a/issues/build/a-metal-run-asks-ubuntu-which-machine-it-is-and-the-boot-says-nothing.md b/issues/build/a-metal-run-asks-ubuntu-which-machine-it-is-and-the-boot-says-nothing.md new file mode 100644 index 00000000000..72312e6fb3a --- /dev/null +++ b/issues/build/a-metal-run-asks-ubuntu-which-machine-it-is-and-the-boot-says-nothing.md @@ -0,0 +1,30 @@ +--- +status: open +kind: tooling +opened: 2026-09-29 +--- + +# A metal run asks Ubuntu which machine it is, and the boot under test says nothing + +`src/metal.rs`'s `run` asks the operating system the T14 runs between boots +for `metaltimings::Machine::QUERY` over ssh before the flash, and writes the +answer into the readback's `boot.txt` under three keys (`VENDOR_KEY`, +`PRODUCT_KEY`, `BIOS_KEY`); `tests/common/metal.rs` reads it back with +`metal::machine`, and `metaltimings::Record::load` picks the machine's record +by it. Both T14 runs of `wt/toyos-metaltimings` named the machine this way: +`machine LENOVO 20W0003AMZ, BIOS N34ET71W (1.71 )`. + +A resident runner, tests inside a ToyOS that stays up on the machine with no +Ubuntu and no reboot per test, has nothing to ask: the ssh read, +`Refusal::Machine`, the three keys and `metal::machine` all go with Ubuntu. +The record compares BIOS strings byte for byte, so identity has one reader: +two that trim differently fail every run as a firmware change. + +## Exit condition + +The boot names its machine: the loader reads SMBIOS type 1's manufacturer and +product and type 0's BIOS version from the UEFI configuration table before +`ExitBootServices` and writes them as one `loader.log` line, the judge reads +the machine from the readback's `loader.log`, the ssh read, `Refusal::Machine`, +the three keys and `metal::machine` are deleted, and every record under +`tests/metal/` names its machine in the loader's own strings. diff --git a/issues/build/a-metal-timing-record-never-tightens.md b/issues/build/a-metal-timing-record-never-tightens.md new file mode 100644 index 00000000000..5da31ff180f --- /dev/null +++ b/issues/build/a-metal-timing-record-never-tightens.md @@ -0,0 +1,20 @@ +--- +status: open +kind: tooling +opened: 2026-09-29 +--- + +# A metal timing record never tightens + +`src/metaltimings.rs`'s `judge` adds a name its machine has not recorded and +never moves one it has, so a run cannot loosen the record that judges it. The +same rule keeps a speed-up out: a number that halves keeps its old ceiling, +and a regression that later doubles it back is inside that ceiling and passes. +Only deleting the row re-records it. + +## Exit condition + +A recorded number that a run measures well under its record is either taken +as the new record by a rule that a noisy run cannot ratchet into a false red, +or reported by name so the row is deleted, and the choice is in +`src/metaltimings.rs`'s module doc. diff --git a/issues/build/the-metal-loop-cannot-judge-a-boot-that-panics.md b/issues/build/the-metal-loop-cannot-judge-a-boot-that-panics.md index 6d24968cf73..c90ef0f23f8 100644 --- a/issues/build/the-metal-loop-cannot-judge-a-boot-that-panics.md +++ b/issues/build/the-metal-loop-cannot-judge-a-boot-that-panics.md @@ -18,9 +18,7 @@ the T14, and the reason is the loop rather than the kernel. `Boot: complete (Nms)` *and* a trailing `Rebooting.`. A boot whose subject is a panic correctly writes neither the second word nor anything after it, so the loop refuses it — the readback is still written, and - `tests/common/metal.rs`'s `Mode::Drive` tolerates the non-zero exit, but the - boot-level rows `tests/metal-profile.toml` prices are then judged against a - log the loop has already called unfit. + `tests/common/metal.rs`'s `Mode::Drive` tolerates the non-zero exit. 2. `test-late-panic` fires in `kernel_main` after `spawn_init` and before `enter_idle_loop`, so `logd` has not run: that boot writes no `/log` file at diff --git a/issues/build/the-usbload-boot-measures-a-panel-no-profile-row-prices.md b/issues/build/the-usbload-boot-measures-a-panel-no-profile-row-prices.md deleted file mode 100644 index 4d22e673862..00000000000 --- a/issues/build/the-usbload-boot-measures-a-panel-no-profile-row-prices.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -status: open -kind: tooling -opened: 2026-09-29 ---- - -# The `usbload` boot measures a panel no `tests/metal-profile.toml` row prices - -`tests/metal-profile.toml` prices `panel_max_us` and `panel_us` for every -metal boot but `usbload`, whose sealed page carries the panel census like any -other. `tests/common/metal.rs` fails a measured number with no row, so every -run that flashes `usbload` reds for it, whatever -`usb_reset_records_the_phase_it_cut` — the boot's one rider — says. - -## Measured - -The full T14 run of `main` at `7e151819` -(EXIT=1): - -``` - usbload: Boot: complete 1166 ms, back in 164 s, the stick enumerated 0 s after that - the panel painted 10 time(s) and put 8741120 px on the glass - FAIL the metal suite measured "boot.usbload.panel_max_us" and tests/metal-profile.toml prices no such number; add a row with a ceiling and where it came from, because a measurement with no ceiling cannot fail - FAIL the metal suite measured "boot.usbload.panel_us" and tests/metal-profile.toml prices no such number; add a row with a ceiling and where it came from, because a measurement with no ceiling cannot fail -``` - -## Exit condition - -`tests/metal-profile.toml` carries `boot.usbload.panel_max_us` and -`boot.usbload.panel_us` rows, each ceiling taken from a measurement of that -boot rather than chosen, and a T14 run that flashes `usbload` prints -neither refusal. diff --git a/issues/diagnostics/the-lanleasecase-boot-is-a-third-t14-flash-for-one-exit-code.md b/issues/diagnostics/the-lanleasecase-boot-is-a-third-t14-flash-for-one-exit-code.md index 2b1db4a1aa5..731723d4006 100644 --- a/issues/diagnostics/the-lanleasecase-boot-is-a-third-t14-flash-for-one-exit-code.md +++ b/issues/diagnostics/the-lanleasecase-boot-is-a-third-t14-flash-for-one-exit-code.md @@ -17,8 +17,7 @@ reaches no file (`issues/diagnostics/the-cable-judge-reads-three-netd-records-that-cannot-arrive-on-the-t14.md`): the kernel's `exit: netd pid=N code=N` record and a file netd writes itself are the two words of a process that cross. It is the `lan_lease_report` metal row, -a third image flashed to the stick, a third boot of the machine and six rows of -`tests/metal-profile.toml`. +a third image flashed to the stick and a third boot of the machine. ## Owner @@ -32,7 +31,7 @@ which the shipping `lancase` arm carries netd's own lines about the lease and the probe answers a question already answered. Then the arm is: `tests/lanleasecase/system.toml`, its row in `src/build.rs`'s `ALL_CONFIGS`, the `lan_lease_report` metal row in `tests/toyos.rs` with `LANLEASECASE` and -`lan::leased_on_metal`, the six `tests/metal-profile.toml` rows, +`lan::leased_on_metal`, `userland/netd/src/report.rs` and `toyos-i219/src/lease.rs`'s report lines — and netd's `--exit-with-lease` with `tests/e1000leasecase` and the `lan_lease_report` QEMU registration, the arm that proves the channel. diff --git a/issues/hardware/a-boot-with-no-kernel-log-is-not-no-boot-complete.md b/issues/hardware/a-boot-with-no-kernel-log-is-not-no-boot-complete.md index b23fed10af3..8c350ce6f26 100644 --- a/issues/hardware/a-boot-with-no-kernel-log-is-not-no-boot-complete.md +++ b/issues/hardware/a-boot-with-no-kernel-log-is-not-no-boot-complete.md @@ -22,8 +22,7 @@ readback could say about the run-22 class of hang. **Exit condition**: the loop names that case as itself — a readback with no `logd` file and no harvested report reported as "wedged before its first durable -record", distinct from "no `Boot: complete`" and from "no readback at all" — and -a metal-profile row that says which of the three a boot is. +record", distinct from "no `Boot: complete`" and from "no readback at all". Off the path of whoever finds this: it is `src/metal.rs`'s verdict and belongs to the driver, not to the kernel side that produced the boot. diff --git a/issues/hardware/metalprobes-usb-read-is-answered-from-fsds-cache.md b/issues/hardware/metalprobes-usb-read-is-answered-from-fsds-cache.md index ff88f3818e9..aa89729ed65 100644 --- a/issues/hardware/metalprobes-usb-read-is-answered-from-fsds-cache.md +++ b/issues/hardware/metalprobes-usb-read-is-answered-from-fsds-cache.md @@ -11,9 +11,9 @@ and times reading it back as "a cache miss the stick has to answer" — true while the kernel's write-back dropped a closed file from its cache. `/log` is served by `/system/bin/fsd` now, whose block cache (`userland/fsd/src/cache.rs`) keeps clean blocks until it holds `CLEAN_LIMIT` of them and drops nothing at a -close. So the timed read is fsd's memory, and the `usbread` span -`tests/metal-profile.toml` prices is no longer the stick's. +close. So the timed read is fsd's memory, and the `usbread` span is no longer +the stick's. **Exit**: the timed read is one the stick answers — a file fsd has not read since it started, or a read through the partition claim that bypasses the -file server — with the profile row re-measured on the T14. +file server. diff --git a/issues/hardware/the-lanicscase-boot-is-a-second-t14-flash-for-one-question.md b/issues/hardware/the-lanicscase-boot-is-a-second-t14-flash-for-one-question.md index 27b2a5ff9c8..6f44546b60c 100644 --- a/issues/hardware/the-lanicscase-boot-is-a-second-t14-flash-for-one-question.md +++ b/issues/hardware/the-lanicscase-boot-is-a-second-t14-flash-for-one-question.md @@ -10,9 +10,7 @@ opened: 2026-09-13 `--provoke-message`, which writes one enabled cause to `ICS` so the kernel's `pcidev: slot N took its first message` record says whether delivery works at all. It is the `lan_message_delivery` metal row, a second image flashed to the -stick, a second boot of the machine and six rows of `tests/metal-profile.toml` -(`boot.lanicscase.{complete_ms,back_secs,stick_secs,panel_max_us,panel_us}`, -`list.lanicscase.job_ms`). +stick and a second boot of the machine. **A count of no messages is two facts** — a part nothing made speak and a message that reached no CPU — and only this arm separates them. On a card that @@ -30,8 +28,7 @@ The shipping `lancase` arm recording `pcidev: slot N took its first message` without the actuator. Then the actuator has no question left and the arm is four files: `tests/lanicscase/system.toml`, its row in `src/build.rs`'s `ALL_CONFIGS`, `tests/toyos.rs`'s `lan_message_delivery` row, its `METAL_ONLY` -entry and `LANICSCASE` with the judge `lan::provoked_on_metal`, and the six -`tests/metal-profile.toml` rows. +entry and `LANICSCASE` with the judge `lan::provoked_on_metal`. Metal run 57 recorded `pcidev: slot 0 took its first message on vector 0x28` after the I219's hand-over on that slot and vector, so the second fact is read: diff --git a/issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md b/issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md index 0516d530fa0..1b0519288fc 100644 --- a/issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md +++ b/issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md @@ -107,16 +107,10 @@ runner asks for no reboot; the deadline was the only bound left, and it fired ## The instrument that measures this already exists `src/metal.rs:1591-1597`'s `deadline_lateness_ms` computes exactly -`reached − bound` out of the `DEADLINE_EXPIRED` line (`src/bootlog.rs:28`); -`tests/common/metal.rs:274-275` reads it off every readback and `:895-919` -hands it to `profile.judge` as `boot.