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

[Japabu]

One boot answered the question this branch was opened for: whether a message the T14's I219 raises reaches a CPU. The arm that asked the next question is retired.

What the branch carries

tests/lanicscase: netd's --provoke-message, and its own metal row. The boot is
tests/lancase with one argument added to netd's manifest row. After the mask is
armed, I219::provoke_message writes §10.2.4.4's ICS once with LSC. The shipping
config beside it arms none of this, so its own first-message record still means
the card spoke on its own. netd armed with --provoke-message on a card with no
such actuator (virtio) panics naming it, and it does so before VirtioNet::open
touches the card. Each opener in CARDS takes the flag. The Intel opener provokes
once the card is up.

The judge is lan_message_delivery, a metal row of its own over
LANICSCASE, beside lan_dhcp_lease over LANCASE. Each is reported with its own
PASS/FAIL line, so a delivery regression is printed by name while lancase is red
(which it is on every T14 boot until the PHY is brought up). The row carries its
exit condition: it is folded into the lancase judge when the PHY lands (#453),
because lancase's own first-message record then carries the same fact.

The gate changed so it can say this. check_metal_registration refused every
metal row whose name no QEMU registration holds, and no QEMU arm can answer for this
one: it asks about the T14's I219 behind that machine's interrupt remapping. So the
gate gains METAL_ONLY in tests/toyos.rs, a table of (name, why no QEMU arm answers for it). The gate asserts that every METAL name is exactly one of
registered or metal-only; that every metal-only name is run by a METAL Runs row;
and that each has a non-empty reason and appears once. That rule is now
metal_rows_are_registered, a function over the three tables.
the_metal_gates_refuse_what_they_name runs it on fixtures before it runs on the
real tables: one accepted table for each accepting arm, and one refused table for
each refusal, matched by its words.

A METAL_ONLY name the shared boot answers under is refused
(metal_only_is_unshared, fixture-tested the same way). The shared names are
every discovered Rust test, every C case, and every name a shared metal boot's
members are recorded under, taken unfiltered. The check runs on the ordinary path
beside check_no_collisions and on the --metal path before anything is staged.

The judge reads the function's own records (toyos_build::lan::delivered,
pure, in src/lan.rs). It finds the kernel's pcidev: PCI … [8086:15fc] handed over on slot N, vector V record and accepts only a line whose whole message is the
kernel's pcidev: slot N took its first message on vector V, for that N and V,
after the hand-over and before that slot's next hand-over. A hand-over clears the
slot's record, so a record after the next one answers that claim. A refusal names what was missing or mismatched: no hand-over
(quoting the kernel's NOT HANDED OVER line if there is one); no matching record;
and, on separate lines, each other claim's record, each line not in the kernel's
spelling, a matching record that came before the hand-over, and the slot's next
hand-over with a matching record after it. Run 57's log, verbatim from the
hand-over to the record, is a unit-test fixture. The review's K2, K4, K5, K6 and K7
are unit tests built as edits of it. So is a hand-over line written by another
writer, which holds the pcidev: PCI prefix check. Another test reads both
format literals out of kernel/src/pcidev/mod.rs whole, joining line continuations
the way the compiler does, and compares each with the spelling this judge parses.

Host-side: toyos_i219::I219::provoke_message, netd's PROVOKE_MESSAGE, and two
unit tests. a_cause_written_to_ics_raises_a_message_the_claim_takes asserts
exactly one message and exactly the cause set LSC | OTHER (OTHER is
§10.2.4.1's summary bit, set with LSC), INT_ASSERTED aside. Its negative control
is a_pass_with_no_provoked_cause_takes_no_message.

tests/metal-profile.toml prices lanicscase, including the per-boot
panel_max_us and panel_us rows, at lancase's ceilings.

The hardware measurement, and the two checks

Independent oracle: real hardware, two runs of the same lanicscase image at
4d604c86. Metal run 57 recorded pcidev: slot 0 took its first message on vector 0x28 (userdev=1), after the I219's hand-over on slot 0, vector 0x28. Run 54
did not come back within 420 s and left no kernel log in its readback, so it says
nothing either way. From run 57: MSI delivery from that function works on that
machine, so the userdev=0 of run 36 is a part that raised nothing, not a message
that reached no CPU. Nothing in the judge's records says the message run 57 took was
the provoked one rather than one of open's own causes. What it establishes is
delivery from this function, not which cause was delivered.

Negative controls, each a checked patch applied and restored in one script, the
mutated tree shown to build, and the tree clean after:

provoke_message: ICS <- u32::MAX        build EXIT=0  cargo test -p toyos-i219  EXIT=101
    tests.rs:681 "the causes read are not exactly the one written"  (left 0x7fffffff, right 0x01000004)
provoke_message: ICS <- LSC, twice      build EXIT=0  cargo test -p toyos-i219  EXIT=101
    tests.rs:674 "one cause written to ICS once is one message"  (left 2, right 1)
delivered: substring match, any line    build EXIT=0  cargo test -p toyos-build --lib lan::  EXIT=101
    3 failed: a_line_that_is_not_the_kernels_record…, another_slots_record…, the_record_before_the_hand_over…
restored                                 cargo test -p toyos-i219  EXIT=0  33 passed

The review's no-op, RXT0, ICR, IMS and read-and-ack mutants were already red.

Round 3's mutations, run the same way (git apply --check, apply, build, run,
git apply -R; git status --short empty after):

delivered: search not ended at the slot's next hand-over   build EXIT=0  lan::  EXIT=101  a_record_after_the_slot_is_handed_over_again_is_refused
delivered: `pcidev: PCI ` prefix check dropped             build EXIT=0  lan::  EXIT=101  a_hand_over_not_in_the_kernels_spelling_is_refused
kernel pcidev/mod.rs:618 `vector {:#x}` -> `vector {}`     kernel cargo check --release EXIT=0  lan::  EXIT=101  the_kernel_writes_both_records_in_the_spelling_read_here
G5: the row and its METAL_ONLY entry -> abuse_connect_flood  build EXIT=0  --metal --metal-readback K1 abuse_connect_flood  EXIT=101
    "METAL_ONLY declares [\"abuse_connect_flood\"], which the shared boot also answers for …"
G6: `_ if true => {}` ahead of the gate's match             build EXIT=0  --metal --metal-readback K1 lan_message_delivery  EXIT=101
    "the metal registration gate on an unregistered row answered Ok(()), and it has to answer a refusal saying \"which no registration names\""

The judge on the review's readbacks (cargo test --test toyos-build -- --metal --metal-readback <dir> lan_message_delivery):

K1 (run 57 verbatim)                 PASS lan_message_delivery
K2 (record deleted)                  FAIL: … handed over on slot 0, vector 0x28, and no kernel record `pcidev: slot 0 took its first message on vector 0x28` follows it …
K4 (record deleted, userland line)   FAIL: the same, and "a line not in the kernel's spelling of the record: … test-runner: waiting until netd took its first message"
K5 (record on slot 1, vector 0x30)   FAIL: the same, and "another claim's record, not this function's: … slot 1 took its first message on vector 0x30"
K6 (15fc not handed over)            FAIL: no `[8086:15fc] handed over on slot ` record, and the kernel refused a function: … NOT HANDED OVER: refused
K7 (slot 0 handed to 8086:a0f0, then slot 0's record)   FAIL: … no kernel record … follows it, and "the slot, handed over again: … [8086:a0f0] handed over on slot 0, vector 0x28" and "the record, after the slot was handed over again: …"
K9 `0X28`, K10 `vector 40`, K11 trailing text, K12 record only before, K13 no bracket   each FAIL lan_message_delivery: … no kernel record … follows it

K8 was not run: the review ruled its refusal a false red, not a false pass, and
this round leaves it.

Every one of those invocations exits 1, K1 included. The reason is the per-boot rows:
boot.lanicscase.panel_max_us and panel_us are priced, and run 57 recorded no
panel census. The review's own runs show the same two FAIL lines. The run over
K1 with the filter lan reports both rows independently:
FAIL lan_dhcp_lease (no cable on that readback) and PASS lan_message_delivery.

The retired arm, and why

--read-manageability (tests/lanmngcase) was the second experiment: one read
of EXTCNF_CTRL (§10.2.2.15), no write, no PHY register touched, then exit
with the reading encoded in the code.

Both of its boots found the machine off. In runs 58 and 62 the machine was
found off, not frozen, with no black box. On both runs the persisted kernel log
ends at the same first logd batch: 192 lines, around 0.6 s. The cause is not
known and nothing on the stick says what it was.

So the arm is removed whole, and the question it asked is asked through the PHY
probe's exit code on PR #453. Nothing of it remains in the net diff against
main: no flag, no boot, no Manageability type, no EXTCNF_CTRL register, no
profile rows, and no change to Cargo.toml or Cargo.lock. What happened is
filed as
issues/hardware/both-boots-of-the-manageability-read-image-found-the-t14-powered-off.md,
with no speculation about the cause.

Tracker

• issues/hardware/the-i219s-phy-is-never-brought-up-and-the-part-raises-no-interrupt.md
  is now issues/hardware/the-i219s-phy-is-never-brought-up.md, status: assigned
  to PR The I219 PHY bring-up is judged under both readings of the MDIO arbitration, and its outcome crosses the T14 as netd's exit code #453, with an exit condition and its citation of a Linux driver's source removed.
• issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md
  names this branch and this PR.
• Filed: issues/hardware/the-t14-lan-judge-owes-netd-records-the-stick-never-carries.md.
  A console-object write goes to the serial backend and not into the record ring
  logd persists, and run 57's log carries no netd: line at all. So
  lan_dhcp_lease's metal judge owes records no T14 boot can carry.

The merges

origin/main at 909f34b4 is merged in. git merge origin/main at the start of
round 3 was already up to date. Never rebased.

Gates on 092b7192, each the command's own exit status

cargo test -p toyos-i219                                   EXIT=0   33 passed
cargo test -p toyos-build --lib                            EXIT=0   299 passed; 0 failed; 1 ignored
cargo test --workspace --exclude toyos-build               EXIT=0   139 suites ok, 0 failed
cargo run -- --clippy                                      EXIT=0
cargo test                                                 EXIT=0   test result: ok. 347 passed, 8 quarantined and green, 347 total, 103 held back for the nightly tier
metal judge, K1                                            PASS lan_message_delivery (the invocation exits 1 on the two panel rows, as above)
metal judge, K2 K4 K5 K6 K7 K9 K10 K11 K12 K13             each FAIL lan_message_delivery, EXIT=1

The toyos-i219, lib and workspace runs were on 4e763793. 092b7192 changes only
tests/toyos.rs, which none of those three builds. Clippy, the fast tier, K1, G5 and
G6 were run again on 092b7192.

Unsure

• netd's --provoke-message path (argument, Card, Nic, driver) runs in no CI
  boot; only a T14 boot reaches it. No T14 run is requested this round. What the
  image does to the part is unchanged: the Intel opener writes the same ICS once,
  now inside Card::intel right after open, where main used to write it. The
  virtio refusal moved ahead of open, and tests/lanicscase cannot reach it
  because it claims only pci:8086:15fc.
• The judge tells the kernel's record from another writer's line by its whole
  message, not by origin: a record carries no writer tag a userland line could
  not also spell. On this machine no userland write reaches the ring logd
  persists (see the filed issue), so no userland line can reach the file the
  judge reads.
• K8 (a second 15fc hand-over on slot 1, then slot 1's record) is still refused,
  because the judge reads the first 15fc hand-over. That is a false red, not a
  false pass. The kernel cannot produce it while one claim holds the function.
• Why the manageability read's boots found the machine off is unexplained; the issue stays open.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK

[Japabu]

Review of #461 at 510b6923 against origin/main 909f34b4.

CI on 510b6923: every job's conclusion is success or skipping (landing, toolchain, ci, host tests runs all headSha=510b6923, conclusion=success). toyos-i219 in a scratch copy: EXIT=0, 33 passed. The independent oracle is metal run 57 at 4d604c86, not this head. 16 kernel files moved since then through main, kernel/src/pcidev/mod.rs among them. The branch itself changes no kernel file.

Measurements:

• Host mutations of provoke_message, run in a scratch copy of the crate; each mutated copy built. These went red: no-op; ICS←RXT0 (red at tests.rs:679); write to ICR instead; write to IMS instead; ICS then read/ack ICR. These stayed green (EXIT=0, 33 passed): ICS←u32::MAX, and ICS←LSC written twice.
• The metal judge, run for real (cargo test --test toyos-build -- --metal --metal-readback <dir> lan_dhcp_lease) on readbacks built from run 57's kernel log. Logs are i219del-review-judge-K*.log.
  • K1, run 57 verbatim: the provoke half is Ok.
  • K2, the took its first message record deleted: the verdict line quotes only lancase's missing cable. The provoke half's refusal is never printed.
  • K4, the record deleted and a test-runner: waiting until netd took its first message line added: accepted.
  • K5, the record rewritten as slot 1 took its first message on vector 0x30 while 15fc is on slot 0: accepted.
  • K6, 15fc's hand-over replaced by NOT HANDED OVER and the record rewritten to slot 3: accepted.

BLOCKER

• tests/toyos.rs:1309 — on_metal(b[0]).and(provoked_on_metal(b[1])) throws away the delivery judge's Err whenever lancase fails. Lancase fails on every T14 boot until the PHY is brought up (run 57's log shows no link). So the arm cannot report a delivery regression: K2 shows the refusal text is never printed. Hanging it off lan_dhcp_lease to get past check_metal_registration is a workaround of that gate. Give it its own verdict, or report both halves.
• tests/common/lan.rs:44 — provoked_on_metal accepts any line containing the substring. It is not tied to the [8086:15fc] handed over on slot N, vector V record. K4 (a userland line), K5 (another slot) and K6 (a boot where 15fc was refused) all pass. The oracle for "MSI from this function reaches a CPU" does not look at this function.
• toyos-i219/src/tests.rs:675 — messages > 0 plus causes & LSC != 0 stay green when provoke_message writes u32::MAX to ICS, and when it writes LSC twice. The claim is one enabled cause, once, and on driver code the test has to be able to fail on that claim. Pin pass.messages == 1 and the exact cause set.

NOTE

• userland/netd/src/main.rs:131 — an instrument armed on a card it cannot drive says a line and carries on. The judge would then read virtio's own first message as a pass. Refuse loudly instead. It is unreachable while tests/lanicscase claims only pci:8086:15fc.
• netd's --provoke-message path (arg → Card → Nic → driver) runs in no CI boot. Only a T14 boot reaches it.
• The oracle is 1 of 2: run 54 was this same lanicscase image at 4d604c86 and did not come back within 420 s. It left no kernel log in its readback. The PR mentions only run 57.
• The arm only tells you something while the link is down. Once the PHY is up, lancase's own first-message record carries the same fact. Give it an exit condition, or fold it into the lancase judge when The I219 PHY bring-up is judged under both readings of the MDIO arbitration, and its outcome crosses the T14 as netd's exit code #453 lands.
• Power-off question: nothing on this branch plausibly explains it, and the evidence does not rule it out. Evidence:
  • What the branch sends to the part is one ICS←LSC write on the lanicscase image only. It touches no wake or power register, no PHY, and nothing on MEI 00:16.0. The shipping lancase does exactly what main does.
  • Run 57 took that one message (userdev=1) while netd was live, and begin_pass write-clears ICR. The next boot's open starts with IMC←all, a read of ICR and a MAC reset.
  • Against the ICS write as the cause: images without it fail the same way.
    • Run 55 and run 56 are unarmed lancase at the same head. 55 did not come back; 56 has no Boot: complete.
    • Runs 67 and 68 are lanphycase from PR The I219 PHY bring-up is judged under both readings of the MDIO arbitration, and its outcome crosses the T14 as netd's exit code #453. Neither came back, and both kernel logs end at the same 192-line first batch as runs 58 and 62.
    • Run 68 started from a full power-on, so no state was inherited from an ICS boot.
  • For it, and not excluded: run 58 (off) directly followed run 57, the only completed ICS boot, and run 54 (ICS) did not come back.
• src/build.rs, tests/metal-profile.toml, the lanicscase config and the tracker moves are fine. No Linux citation, no INTx, no MEI and no ABI appear in the added lines (git diff | grep '^+' for linux/e1000e/ich8/mei/intx is empty).

REMOVE

• issues/hardware/both-boots-of-the-manageability-read-image-found-the-t14-powered-off.md:16 — "before netd ran at all": logd, which wrote that batch, spawned at 1.329 s and netd at 1.518 s (run 57). A log ending at logd's first batch does not say netd never ran. The same clause is in the PR body.
• issues/hardware/both-boots-of-the-manageability-read-image-found-the-t14-powered-off.md:20 — "Every other image booted clean… no others": runs 54, 55, 67 and 68 did not come back, and 67 and 68 end at the same 192-line batch. The same claim is in the PR body.
• tests/lanicscase/system.toml:6, userland/netd/src/main.rs:1327 — "the first message this claim takes is one netd asked for": nothing sets the order between open's own causes and the ICS write, and no judge can tell them apart.
• tests/common/lan.rs:53 — "netd wrote one cause to ICS on this boot": the judge reads nothing that says so.

SEND BACK

[Japabu]

Round 2 review of #461 at 5e49989b, against round 1 at 510b6923. The delta is one commit, 5e49989b. It carries no merge of origin/main.

CI on 5e49989b: the landing, toolchain, ci and host tests runs are all pull_request, headSha=5e49989b, conclusion=success. The three skipped jobs are nightly-red, nightly-red-host and tcg. cargo test -p toyos-build --lib lan::: EXIT=0, 14 passed. toyos-i219 in a scratch copy: EXIT=0, 33 passed.

Round 1 BLOCKERs

• CLOSED: tests/toyos.rs:1309, the delivery judge's Err swallowed behind lancase. lan_message_delivery is now its own row. On K2 (run 57 with the record deleted) it prints FAIL lan_message_delivery: 8086:15fc was handed over on slot 0, vector 0x28, and no kernel record … follows it. With filter lan_ on K1, both rows report on their own: lan_dhcp_lease FAIL, lan_message_delivery PASS.
• CLOSED: tests/common/lan.rs:44, the substring judge. The metal judge was run on the constructed readbacks, filter lan_message_delivery:
  • K1 (run 57 verbatim): PASS.
  • K4 (a userland line): refused, named as "a line not in the kernel's spelling".
  • K5 (slot 1): refused, "another claim's record".
  • K6 (15fc NOT HANDED OVER, then slot 3): refused.
  • These new readbacks are refused too: K9 0X28, K10 decimal vector 40, K11 trailing text, K12 the record placed only before the hand-over, K13 no bracket prefix.
  • K8 (a second 15fc hand-over on slot 1, then slot 1's record) is refused. That is a false red, not a false pass.
  • Unit mutations: dropping skip(at + 1) goes red at the_record_before_the_hand_over_answers_nothing. Matching any vector goes red at another_slots_record_is_refused_as_another_claims.
• CLOSED: toyos-i219/src/tests.rs:675, a test too weak to fail. The same scratch-copy mutations of provoke_message were built and run:
  • ICS←u32::MAX: red, tests.rs:681.
  • LSC written twice: red, tests.rs:674.
  • LSC|RXT0: red.
  • no-op: red.
  • LSC|OTHER stays green. That mutation is equivalent under stub.rs:353, which sets OTHER whenever LSC is raised.

Panel rows: boot.lanicscase.panel_max_us and panel_us fail on K1. That is expected and is not a defect in how this arm is judged. The census commit 20c87afc is not an ancestor of run 57's 4d604c86 (git merge-base --is-ancestor is false), so that kernel wrote no census. A boot of this head would write one.

BLOCKER

• tests/toyos.rs:18303 — METAL_ONLY accepts a name the QEMU shared boot answers under — measured as mutation G5: the lan_message_delivery row and its METAL_ONLY entry renamed to abuse_connect_flood, a discovered Rust test. The gate passed (EXIT=2, staged). The run reported 1 registration(s) and 1 shared member(s), which is two verdicts under one name. The gate before this change refused any METAL row outside MACHINE/SCREEN/AUDIO. check_no_collisions compares only declared names against shared ones, so nothing else catches it. This is a QEMU test hiding behind a declaration that says no QEMU arm answers for it. Refuse any METAL_ONLY name that the shared registry (Rust or C) or a shared metal member carries.

NOTE

• src/lan.rs:143 — the search for the first-message record does not stop at a later hand-over of the same slot. K7 hands [8086:a0f0] over on slot 0, vector 0x28 after the I219, followed by slot 0's record, and it is accepted: PASS lan_message_delivery. IRQ[slot].clear() on hand-over makes a fresh first-message record after a slot is released and reused, so the kernel can produce this log. It cannot happen on lanicscase, which has one claimant. The fix: end the search at the next handed over on slot {slot}, record.
• src/lan.rs:392 — the spelling test holds only the first physical line of the hand-over format. Changing kernel/src/pcidev/mod.rs:618 to vector {} keeps the_kernel_writes_both_records_in_the_spelling_read_here green (EXIT=0). The mutated kernel passes cargo check --release (EXIT=0); the control, an extra {}, does not compile. The judge would then false-red every boot with "carries no readable slot and vector". Changing the verb or the took format does go red (EXIT=101).
• src/lan.rs:122 — dropping the pcidev: PCI prefix check keeps all 14 tests green. No fixture carries a non-kernel line with the hand-over words. Low stakes: SYS_LOG_READ is the only log syscall, so userland cannot write the ring.
• The check_metal_registration arms have no fixture test of their own. Mutation G6 (_ if true => {} ahead of the match) stays green on the real tables. G1 (empty), G2 (registered too), G3 (no METAL row) and G4 (blank reason) each panic at the named assert, so the tables are checked, but the gate code is not.
• userland/netd/src/main.rs:134 — the panic comes after open(claim) has already brought the virtio card up. A refusal before open would touch nothing. It is unreachable while lanicscase claims only pci:8086:15fc.

REMOVE

• tests/common/lan.rs:4 — "into which netd's say! writes, being a write to a console object": the new issue file says this is false, and this branch's own line 39 says the opposite.
• tests/toyos.rs:251 — "lan_dhcp_lease's metal arm is the only job list that names it": lan_message_delivery's LANICSCASE now runs lan::JOBS too.
• userland/netd/src/main.rs:129 — "that card's own first message would read as the instrument's": the judge now requires a [8086:15fc] handed over record, and K6 shows a boot without one is refused.

SEND BACK