From d44ba2371c7230ca9c84774b54f6df5a5eff0833 Mon Sep 17 00:00:00 2001 From: japabu Date: Wed, 28 Oct 2026 22:34:48 +0100 Subject: [PATCH 1/3] issues: the AMD row's staged fault reds every T14 testcases boot The T14's 00:0d.0 is a spare xHCI under both boot layouts: off the stick 00:14.0 is the boot controller, and off the NVMe (#1095) no xHCI is. The AMD-Vi row amdvi_usbd_drives_its_own_entry claims it and aims its command ring past its grant, and klogd_hosted's must_be_clean refuses that staged fault. PR #1074's four stick boots and its NVMe landing boot all show it. The record that a metal row names no machine already holds this mechanism. It gains those boots and the other rows that red with it: four AMD-bench rows by the same mechanism, and i219 and hda_tone, which have records of their own. It also gains its owner. Evidence: https://github.com/ToyOSOrg/evidence/tree/b1c036144b4c8a39415cb60145a823d0c0d2d652/r3 https://github.com/ToyOSOrg/evidence/tree/3cb575aadca9e85f33b4c5690c7e1ea4ca15822f/r8 Co-Authored-By: Claude Opus 5.5 --- ...chine-so-another-benchs-boot-carries-it.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md b/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md index 1dea889b866..005f26a4bd2 100644 --- a/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md +++ b/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md @@ -19,6 +19,32 @@ The stick's controller is no longer pinned per machine (the `@boot` place), so which spare a row claims is decided at boot. Which bench a row runs on is still not declared, and the harness has nothing to refuse it by. +The T14's `00:0d.0` [8086:9a13] is a spare under both boot layouts. Off the +stick, `00:14.0` is the boot controller. Off the NVMe (#1095), no xHCI is. The +AMD row claims the spare and its fault arm runs: +`iommu: DMA FAULT owner=process unit3 stream=00:0d.0 addr=0x0000000050200000`, +1 GiB past the grant at `0x10200000`. `klogd_hosted` then reds on +`must_be_clean`. The fault ran on each of PR #1074's four stick boots +(sessions 2–5), and `klogd_hosted` red on every one judged (sessions 2–4; +[sessions 2 and 3](https://github.com/ToyOSOrg/evidence/tree/b1c036144b4c8a39415cb60145a823d0c0d2d652/r3)). +The same happened on its NVMe landing boot (head 094323f29, +[evidence](https://github.com/ToyOSOrg/evidence/tree/3cb575aadca9e85f33b4c5690c7e1ea4ca15822f/r8)). + +Four more rows red on that boot by this record's mechanism, because they are +AMD-bench rows judged against a T14 readback: +- `amdvi_usbd_drives_its_own_entry`: `test_rs_usbd_spare_vector` finds no + MSI-X on the T14's MSI-only xHCI; +- `idle_entered`: "this row runs on the AMD bench"; +- `amdvi_translates_the_boot_controller` and + `amdvi_remaps_the_boot_controller`: no AMD-Vi unit is translating. + +The boot's two other reds have causes of their own: +`i219_messages_on_its_msi_vector` (`issues/i219-msi-passes-only-when-the-network-sends-it-a-frame.md`) +and `hda_tone` (`issues/the-t14-tone-underran-one-period-once-in-nine-boots.md`). + +**Owner**: the metal harness (`tests/common/metal.rs`, and the row table in +`tests/toyos.rs`). + **Exit**: every metal row declares the machines it runs on, by the SMBIOS identity the machine's record carries. A selection run on one bench takes no row that is not declared for it, and says which rows it left out. From ab6e5cc29260d500955358a17a573dde36bc4e50 Mon Sep 17 00:00:00 2001 From: japabu Date: Wed, 28 Oct 2026 22:34:49 +0100 Subject: [PATCH 2/3] issues: the T14 tone underran one period once in nine boots hda_tone read underruns=1 in its first stats window on PR #1074's landing boot (094323f29). Judged on every distinct T14 testcases boot, it is 1 in 7 boots of #1074's branch, which mix stick and NVMe layouts, and 0 in 2 boots of main 370d7d9f6. That is not attributable. The record states that the cause has no candidate: the signal bell, the one pipe on the path, cannot be refused for memory after delivery in a stream this short in either tree. Its exit asks for an underrun record that names the cause, and does not close on a count of clean boots. Evidence: https://github.com/ToyOSOrg/evidence/tree/9d0ed9325f33f34ba7714fe68ca1261129c27f0a/r9 Co-Authored-By: Claude Opus 5.5 --- ...-underran-one-period-once-in-nine-boots.md | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 issues/the-t14-tone-underran-one-period-once-in-nine-boots.md diff --git a/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md b/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md new file mode 100644 index 00000000000..3e8f55d1077 --- /dev/null +++ b/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md @@ -0,0 +1,49 @@ +--- +status: open +kind: defect +opened: 2026-10-28 +--- + +# The T14 tone underran one period once in nine boots + +`hda_tone` reds when soundserver fills a period the tone client had not +covered (`tests/common/audio.rs`'s `tone_on_metal`). On one T14 `testcases` +boot it read `underruns=1 starve_max=1` in the stream's first 2 s stats +window (11.772–13.773 s of a stream that closed at 14.977 s): one isolated +period, somewhere in that window. The second window and `hda_tone_resampled` +in that boot read 0. + +Distinct T14 boots judged for this row: +- 7 of PR #1074's branch. Four are stick boots of earlier revisions on older + mains, and three are NVMe boots. The NVMe three include the red one (head + 094323f29) and the same image booted again 24 minutes later. +- 2 of main 370d7d9f6 alone, NVMe. + +If both trees underran at one rate, the red would land on a branch boot 7 +times in 9 (3 in 5 counting NVMe boots alone), so the counts attribute it to +neither. +([landing boot](https://github.com/ToyOSOrg/evidence/tree/3cb575aadca9e85f33b4c5690c7e1ea4ca15822f/r8), +[every boot's judgement](https://github.com/ToyOSOrg/evidence/tree/9d0ed9325f33f34ba7714fe68ca1261129c27f0a/r9)) + +There is no candidate cause. The samples cross a shared-memory ring. +soundserver counts an underrun only once a client is streaming, that is once +it has delivered (`ClientStream::is_streaming`). The one pipe on the path is +the signal bell, and after delivery `signal_clients` (`system/soundserver/src/mix.rs`) +rings it once per mix wake. It drops every error but `Gone`, and a bell +refused for memory would be dropped too. But neither tree can refuse that +write for memory in a stream this short: +- on main, a pipe holds its page from its first write; +- with #1074, a pipe that has held a byte needs another frame only when its + held bytes cross a frame's 4096 bytes (`kernel/pure/pipe.rs`'s `wants`, and + `consume` restarts a drained pipe at its frame's start). That takes about + 4096 bells, and this stream rang at most about 1400 (one per mix wake, + 871 + 515). + +**Owner**: soundserver and the hda driver. + +**Exit**: soundserver's underrun record names the period, how late the +client's fill was and how late the device's completion was. A recurrence +then names its cause, and the fix lands. The record does not close on a +count of clean boots. At the observed 1 in 9, 26 consecutive clean boots +are needed to exclude that rate with 95 % confidence, and about 300 to +bound it under 1 in 100. From e671121b3d63a305671cb7f52683f50acee3c35d Mon Sep 17 00:00:00 2001 From: japabu Date: Wed, 28 Oct 2026 22:44:41 +0100 Subject: [PATCH 3/3] review r2: main is named by its revision, and the other reds by their records Co-Authored-By: Claude Opus 5.5 --- ...al-row-names-no-machine-so-another-benchs-boot-carries-it.md | 2 +- issues/the-t14-tone-underran-one-period-once-in-nine-boots.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md b/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md index 005f26a4bd2..e495d477631 100644 --- a/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md +++ b/issues/a-metal-row-names-no-machine-so-another-benchs-boot-carries-it.md @@ -38,7 +38,7 @@ AMD-bench rows judged against a T14 readback: - `amdvi_translates_the_boot_controller` and `amdvi_remaps_the_boot_controller`: no AMD-Vi unit is translating. -The boot's two other reds have causes of their own: +The boot's two other reds have records of their own: `i219_messages_on_its_msi_vector` (`issues/i219-msi-passes-only-when-the-network-sends-it-a-frame.md`) and `hda_tone` (`issues/the-t14-tone-underran-one-period-once-in-nine-boots.md`). diff --git a/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md b/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md index 3e8f55d1077..b71ebfdbfaa 100644 --- a/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md +++ b/issues/the-t14-tone-underran-one-period-once-in-nine-boots.md @@ -32,7 +32,7 @@ the signal bell, and after delivery `signal_clients` (`system/soundserver/src/mi rings it once per mix wake. It drops every error but `Gone`, and a bell refused for memory would be dropped too. But neither tree can refuse that write for memory in a stream this short: -- on main, a pipe holds its page from its first write; +- on main 370d7d9f6, a pipe holds its page from its first write; - with #1074, a pipe that has held a byte needs another frame only when its held bytes cross a frame's 4096 bytes (`kernel/pure/pipe.rs`'s `wants`, and `consume` restarts a drained pipe at its frame's start). That takes about