Repository navigation
os/mini: ship the xHCI capture on the medium, so engine#823's plug test has an instrument - #1679
Conversation
…st has an instrument The capture merged in #1606 lives at tools/xhci_boot_capture.sh, i.e. in the source tree - and engine#823's remaining question is answered ON a booted stick, by plugging into the rear USB-A and Type-C ports and reading per-port connect state. So the one person who can make the measurement could not run the tool: the issue would stay open for want of a script rather than for want of hardware. mkimage.sh installs it as /bin/1bit-xhci-capture (0755, from $src/tools, beside 1bit-release-check), and release-check.sh gains a row that says whether it is there - FAIL, not SKIP, because a medium without the instrument cannot answer the question that medium exists to answer. The verdict is a pure function (xhci_capture_verdict) with three self-test cases (1 -> PASS, 0 -> FAIL, empty -> FAIL), following the file's own convention. Verified: bash -n on both scripts (mkimage is bash; the first check of it with sh -n was mine being wrong, not the script), self-test rc=0 with 169 assertions, the installed copy is a valid sh script at 0755.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 6a72af51.
The live row is computed, not faked — which is the thing I checked first, because a release row that hard-codes its own answer is worse than no row:
if [ -x /bin/1bit-xhci-capture ]; then XC=$(xhci_capture_verdict 1); else XC=$(xhci_capture_verdict 0); fiand xhci_capture_verdict() carries three self-test arms (1 PASS, 0 FAIL, empty → FAIL "could not be read"), so the verdict function is pinned at the same
time the live state is read.
The rationale is the part I would keep above the code: "a tool that lives only in the source tree cannot be run by the person holding the stick, so the issue
would stay open for want of a script rather than for want of hardware". That is exactly right for #823 — the question ("does a rear USB-A or Type-C port see a
device?") can only be answered from a booted system, and the person who can plug something in is not going to clone a repo. install -m 0755 … /bin/1bit-xhci-capture
puts the instrument where the experiment happens.
Pairing it with the earlier capture work also means the medium carries both halves: the script that records (from #1606's era) and now a row that fails the release if
the script is missing.
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
…#2030) On this box `/tmp` is tmpfs, so a capture written there is **RAM held until reboot**. The tool was falling back to `/tmp/xhci-capture-<stamp>` whenever `/data` was not writable, which is the default on a machine without a `/data` mount — so the default path was RAM. The fallback is now `${XDG_CACHE_HOME:-$HOME/.cache}/1bit/captures/xhci-<stamp>`, the directory the `.fconst` and `q4nx` caches already use, and the header says why in one line referencing engine#2027's rule. `/data` is still preferred when it is writable. Why this is this lane's to fix: the tool is mine (#1679), and the rule is fleet-wide as of 2026-11-10 (`/tmp` 52 G on a 122 G box with swap 71/71 G full, every dump and staging file counted as memory). Two of my own earlier capture runs left **root-owned** files in `/tmp` (`Operation not permitted` to a lane, so a sweep cannot finish without sudo) — the class this change removes. Not a general sweep fix: the per-token `q4nx_hidden_%d.bin` dump and the `mkstemp` sites in `npu/forward/` are the larger writers and belong to the lanes editing those files; they were reported separately with line numbers. Verified: `bash -n` clean; `grep -c '/tmp/'` on the file is **0**. Co-authored-by: pi-os3 <pi-os3@1bit.local>
…ve is distinguishable from the KVM (engine#823) (#2044) The capture counts ports that report `connect`, which is the right primary evidence for #823 -- but on this board the count is ambiguous, and the first run of the new section says exactly why: ``` bus 3 port 2: 1d6b:0104 product=USB Emulation Device manufacturer=JetKVM speed=480Mbps bus 3 port 5: 0e8d:0717 product=Wireless_Device manufacturer=MediaTek Inc. speed=480Mbps bus 4 port 1: dcba:4321 product=PID-KKK manufacturer=MID-SSS speed=5000Mbps ``` Three ports report `connect` and **none of them is a storage device a person plugged in**: a JetKVM's USB-emulation dongle (HID + audio + emulated mass storage), the internal Bluetooth radio, and a device whose vendor/product are `dcba:4321` -- a placeholder vendor id, i.e. emulation again. A reader looking at "3 port(s) with connect" would reasonably conclude the rear/Type-C ports work, which is the opposite of this issue's report. So the capture now writes `connected-ids.txt` from sysfs (idVendor:idProduct, product, manufacturer, speed, per connected port) and prints it in the VERDICT above the per-bus count. The one physical action this issue waits on -- plug a known drive and read the VERDICT -- then has a decisive answer instead of a port count: the drive the owner plugs in appears with its own ids, and anything else in that list is identified as what it is. Verified: `bash -n` clean; a run on this board writes the three lines above; the awk that feeds it resolves `bus 3 port 2` and `bus 4 port 1` from a synthetic `ports.txt` (so the section is not vacuous on a machine without a KVM); nothing in the capture writes outside its outdir. Refs #823, #1606, #1679. Co-authored-by: t <t@e.com>
What this fixes
engine#823's software half merged in #1606: the measurement, and
tools/xhci_boot_capture.shto take it. But the capture lives in the source tree, and the remaining question - does a device appear on a rear USB-A or a Type-C port - is answered on a booted stick, by the one person holding it. Nothing on the medium referenced the tool:so the plug test would have had no instrument, and the issue would stay open for want of a script rather than for want of hardware. That is the block, and this PR removes it.
What changes
os/mini/mkimage.sh$src/tools/xhci_boot_capture.shas/bin/1bit-xhci-capture(0755), beside1bit-release-checkos/mini/release-check.shThe row follows the file's convention: a pure
xhci_capture_verdict(1 → PASS, 0 → FAIL, empty → FAIL) with three self-test cases, so the row's own behaviour is asserted rather than assumed.Verification
Not run: a full
release-check.shon a booted medium (that is the owner's boot, and the row is written to be read there). The row is exercised by its three self-test cases here.What the owner's plug test then looks like
On the c33 stick (or c34 once cut), Secure Boot on:
The line that decides #823 is per-port
connectunder== ports seen with a device attachedfor the rear USB-A and each Type-C port: a port that showsconnectwith a drive plugged in closes the issue; one that shows nothing while the front port does is the evidence the issue has been waiting for. The capture also prints the BIOS version beside it, so the reading is always tied to firmware 1.10.Fixes nothing automatically - #823 stays open until a capture shows
connecton a port that does not work today, which needs the owner's hands and a USB drive.