The T14's I219 takes a message netd provokes, judged off its own records, and the manageability read is retired

issues/hardware/both-boots-of-the-manageability-read-image-found-the-t14-powered-off.md

@@ -0,0 +1,25 @@
+---
+status: open
+kind: defect
+opened: 2026-09-21
+---
+
+# Both boots of the manageability-read image found the T14 powered off
+
+A read-only netd job — one read of the I219's `EXTCNF_CTRL` (§10.2.2.15,
+`0x00F00`), no write, no PHY register touched, then `exit` with the reading
+encoded in the code — was flashed to the T14 twice, as metal runs 58 and 62.
+Both times the owner came back to a machine that was **off**: not frozen, not
+wedged at a panic, powered down. Neither boot left a black box.
+
+The persisted kernel log is the same on both runs: it ends at the first `logd`
+batch, 192 lines, at around 0.6 s. So the stick carries nothing from the moment
+the machine went away, and nothing recorded says what took the power.
+
+The cause is unknown. The arm has been removed from the tree rather than left
+armed: the reading it was after is asked through the PHY probe's exit code
+instead.
+
+This closes when a boot records what happened — a black box, a log that reaches
+past 0.6 s, or a firmware event log naming the shutdown — or when nothing needs
+that experiment again.

issues/hardware/the-i219s-phy-is-never-brought-up.md

@@ -0,0 +1,44 @@
+---
+status: assigned
+kind: defect
+opened: 2026-09-13
+---
+
+# The I219's PHY is never brought up
+
+The ThinkPad T14's `8086:15fc` at `00:1f.6` is handed to netd and `I219::open`
+returns `Ok`, but no link ever comes up: nothing in `toyos-i219` touches the
+PHY.
+
+## What `toyos-i219` does not do
+
+The crate is written from the *Intel 82574 GbE Controller Family Datasheet*
+(317694-018), and its module header says so. The 82574 is a discrete PCIe
+controller with its PHY on the same die. The T14's `8086:15fc` is not one: on
+that part the MAC is in the PCH and the PHY is separate silicon the Management
+Engine also drives, reached over an internal interface rather than over the
+register file this crate knows.
+
+The driver's whole bring-up of the link is a MAC reset (`CTRL.RST`, waited on
+until it self-clears) followed by `CTRL.SLU`. On this part that is a MAC reset
+with no PHY handling on either side of it: nothing acquires the semaphore the
+ME shares the PHY through, nothing resets or re-configures the PHY after the
+MAC reset, and nothing takes it out of power down. `CTRL.SLU` lets the MAC
+*see* a link signal; it does not make the PHY produce one.
+
+## What the hardware has shown
+
+Metal run 36 held a boot open for twenty seconds with the function claimed and
+`IMS` armed including `LSC`, and the end-of-boot census read `userdev=0` on
+every CPU: the part raised nothing on its own.
+
+Metal run 57 separated that from a delivery defect. netd wrote `LSC` to `ICS`
+once after arming the mask, and the kernel recorded
+`pcidev: slot 0 took its first message on vector 0x28`. MSI from this function
+reaches a CPU on the T14, so the silence of run 36 is the part having no cause
+to raise — which is what a link that never comes up looks like from outside.
+
+## Exit
+
+Closes when a T14 boot records the I219's link coming up. The bring-up is
+PR #453's (`i219-phy`); the PCH part's datasheet is the source.

issues/hardware/the-t14-lan-judge-owes-netd-records-the-stick-never-carries.md

@@ -0,0 +1,24 @@
+---
+status: open
+kind: tooling
+opened: 2026-09-22
+---
+
+# The T14's lan judge owes netd records the stick never carries
+
+`tests/common/lan.rs::on_metal` (the `lan_dhcp_lease` metal row) refuses a
+readback without netd's `MAC`, `LINK_UP`, `READY` and `LEASE` records, and its
+module header says those reach the stick because netd's `say!` is a write to a
+console object.
+
+It is not. A console-object write goes to `drivers::serial` and the serial
+backend (`ConsoleObject::write` → `ConsoleLine`), never into the record ring
+that `logd` persists; on the T14 that backend is `Backend::None`. Metal run 57's
+kernel log carries no `netd:` line at all, `netd: MAC …` included, which netd
+writes on every boot that opens a card.
+
+So the lancase judge cannot pass on the T14 whatever the network does, and a
+failure it reports for the missing records says nothing about the card.
+
+This closes when the lan judge reads only what a T14 boot can persist, or netd's
+records reach the ring `logd` reads.

issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md

@@ -26,7 +26,7 @@ from bench run 42's kernel log, the text `deadline.rs:174-177` and
     hard lockup: 60000 ms, sampled every 1000 ms by each cpu's own performance counter, after which a cpu that has taken no interrupt seals a WEDGED record and resets the machine
 
 Run 55's boot — armed at 2026-09-14 20:54:57Z, the `lancase` image of the
-unmerged branch `i219-delivery` at `4d604c86`, whose `kernel/src/deadline.rs`,
+branch `i219-delivery` (#461) at `4d604c86`, whose `kernel/src/deadline.rs`,
 `kernel/src/hardlockup/mod.rs` and `kernel/src/drivers/acpi.rs` are
 byte-identical to this tree's (`git diff --stat 4d604c86 HEAD -- <those>` is
 empty) — did not come back inside the loop's 420 s, and its own kernel log

src/build.rs

@@ -2594,6 +2594,7 @@ mod tests {
         "tests/jobcase/system.toml",
         "tests/jobdeadlinecase/system.toml",
         "tests/lancase/system.toml",
+        "tests/lanicscase/system.toml",
         "tests/latencycase/system.toml",
         "tests/logrotatecase/system.toml",
         "tests/metalcase/system.toml",