Bumps base to include the pcid guard (out-of-range PCIe config offsets
return the no-response pattern / no-op instead of aborting pcid) plus
all the operator's ACPI-runtime, i2c, and ided work already on the
submodule branch. This unblocks boot past the previous pcid Invalid
opcode fault, through switchroot and the /usr driver set.
Also carries the earlier accidental commit of the initnsmgr Step 1
Send refactor (Rc<RefCell<Namespace>> -> Arc<sync::Mutex<Namespace>>),
now VALIDATED: a low-load boot progressed through all initfs units,
switchroot, and the /usr drivers via the Arc<Mutex> namespace manager
(hundreds of opens) with no regression. The residual under-load
head-of-line wedge is the known single-threaded initnsmgr issue tracked
in local/docs/INITNSMGR-CONCURRENCY-DESIGN.md (worker-offload / Design B).
Also update LG Gram plan doc: ACPICA assessment (port algorithms,
not the C library), pcid assessment (correct, no changes needed),
Phase 9.1 marked partial (LPIT + _PRW + S0-idle done; MWAIT loop
remains), status updated to reflect completed phases.
Investigated the bootstrap thread bring-up needed for Design A
(worker-offload). Finding: `rlct_clone_impl` requires a fully-built TCB
for the new thread, but bootstrap's freestanding redox_rt has no
Tcb::new / TLS allocator / thread shim (only initialize_freestanding's
single TCB). So Design A needs, as a prerequisite, a freestanding
thread-spawn helper in redox_rt (its own task) — open-coding TCB/TLS in
initnsmgr is not acceptable.
Revised ordering: keep Step 1 (Arc<Mutex> Send refactor, inert until A),
boot-validate on idle + commit; then prefer Design B (kernel O_NONBLOCK
on open + single-thread deferred, no bootstrap threads) as the first
functional step; Design A later once redox_rt grows the freestanding
thread helper. All still require an idle host to validate.
Investigation confirmed Intel display register offsets are IDENTICAL from
Gen8 (Skylake) through Gen14 (Meteor Lake): PIPECONF=0x70008,
PLANE_CTL=0x70180, PLANE_SURF=0x7019C, DDI_BUF_CTL=0x64000, HTOTAL=0x60000.
The only Gen14-specific branch is CHICKEN_TRANS. The original Phase 3.2
hypothesis (per-gen register offset tables) was therefore wrong.
The real gap for MTL was DMC (Display Microcontroller) firmware loading,
which is required for MTL display bringup. This commit adds:
- dmc.rs: Full DMC firmware parser supporting both v1 and v3 header
formats. Parses CSS header, package header, DMC header, validates
magic/version/checksum, then loads payload via MMIO into the DMC
SRAM regions defined by the DMC_PROGRAM() macro.
- DisplayPlatform enum (Gen9/11/12/13/14) with device-id-based
detection covering SKL, KBL, ICL, TGL, ADL, RPL, MTL platforms.
- try_load_dmc() entry point wired into IntelDriver::new() between
forcewake init and display init, matching the Linux i915 sequence.
- 5 unit tests covering header parsing, platform detection, and
payload validation.
Also fixes 4 pre-existing _mmio -> mmio references in virtio test code
that were blocking all test compilation in the redox-drm crate.
Verified: cargo check clean (zero errors, zero warnings from new code).
Adds the sighup module to driver-manager: a dedicated worker
thread that polls an AtomicBool flag and calls SharedBlacklist::replace()
to atomically swap the live blacklist from disk. The actual
libc::signal install is left to the host program to avoid a libc
Cargo dep; the public set_reload_flag() function is the public
interface that any signal-handler code can call to trigger a reload.
sighup.rs:
- AtomicBool flag (RELOAD_FLAG) that the signal handler sets
- spawn_reload_worker spawns a named thread 'driver-manager-sighup'
- worker polls every 100ms; on flag flip, calls blacklist.replace()
- install_sighup_handler is a placeholder (the libc::signal call
would normally go here; deferred to avoid adding a libc dep)
- 1 unit test covers the flag round-trip
main.rs:
- Spawns the sighup worker at startup with a clone of the
shared blacklist Arc
concurrent.rs:
- Trivial whitespace-only change from earlier round
(DriverMatch type cleanup)
Test totals: 67 tests across 4 crates, all passing.
§ 0.5 audit-no-stubs.py: 0 violations across 38 files.
Docs: DRIVER-MANAGER-MIGRATION-PLAN.md v1.7 header + status table;
D5-AUDIT.md v1.7; HARDWARE-VALIDATION-MATRIX.md adds SIGHUP row;
AGENTS.md + docs/README.md pointers to v1.7.
Fourth-round integrations of the driver-manager migration's D-phase.
Three new modules in driver-manager: heartbeat, aer, plus a
SharedBlacklist wrapper around the existing Blacklist that supports
live reload.
heartbeat.rs:
- Heartbeat struct with a publishing thread that writes a JSON
status line to /var/run/driver-manager.heartbeat.json every 5s
- Tracks bound / deferred / spawned / unbound / on_error counters
- 3 unit tests cover counter updates, JSON output, and clone semantics
aer.rs:
- AER (PCI Express Advanced Error Reporting) listener thread
- Reads /scheme/acpi/aer for events (parses severity + device bdf)
- Routes to bound driver via scheme:driver-manager lookup
- Returns RecoveryAction (Handled / ResetDevice / RescanBus) based
on severity
- Falls back to log-and-no-op when /scheme/acpi is absent
- 7 unit tests cover parsing, routing, and severity mapping
policy.rs:
- Adds SharedBlacklist = Arc<RwLock<Blacklist>> + source_path
- Supports live reload via replace() (re-reads from source_path)
- is_blacklisted() takes a read lock (lock-free for the probe hot path)
- set_global_shared_blacklist in config.rs wires it into the manager
- 2 new unit tests cover replace() and snapshot isolation
main.rs:
- Spawns the heartbeat thread at startup (file at /var/run)
- Constructs the SharedBlacklist from the policy directory
config.rs:
- Replaces GLOBAL_BLACKLIST OnceLock<Blacklist> with
OnceLock<SharedBlacklist>; the probe hot path reads via
Arc<RwLock>, not the OnceLock directly
Docs:
- DRIVER-MANAGER-MIGRATION-PLAN.md v1.6 status table (64 tests)
- D5-AUDIT.md v1.6 update
- HARDWARE-VALIDATION-MATRIX.md adds heartbeat and AER rows
- AGENTS.md + docs/README.md pointers to v1.6
Test totals: 64 tests across 4 crates, all passing.
§ 0.5 audit-no-stubs.py: 0 violations across 37 files.
SIGHUP trampoline for the SharedBlacklist is left for a future round;
the replace() infrastructure is in place today so an operator can
add the signal handler without changing the policy module.
Third-round integrations of the driver-manager migration's D-phase.
The pcid_interface crate (in local/sources/base submodule, see
upstream commit ddcd0870) now reads REDBEAR_DRIVER_PCI_IRQ_MODE
and REDBEAR_DRIVER_DISABLE_ACCEL at connect_default time, exposing
them as PciFunctionHandle accessors. The quirk integration is
end-to-end: driver-manager emits the env vars on spawn, pcid_interface
parses them, and the child driver reads the hints from its
PciFunctionHandle.
driver-manager (16 tests, unchanged count + 3 new for observability):
- main.rs: --list-drivers prints the config table, --dry-run
prints how many drivers would-bind/defer/blacklisted without
spawning, --export-blacklist prints the loaded blacklist.
- policy.rs: adds blacklist_module_names() iterator for export.
driver-manager v1.5 quirks.rs (created earlier at v1.4 PciQuirkFlags
work) is in the staging area and is unchanged this round.
local/scripts/driver-manager-audit-no-stubs.py:
- Drops R4 (was: 'let _ = ...' no-op detection) because Rust's
'let _ = expression' is idiomatic and not actually a stub.
- Adds R5 (stub-macro callbacks: unimplemented!/todo!/unreachable!
in callback / fn bodies) to detect dead-end fallbacks.
- Audit gate now reports 0 violations across 35 files (was 34,
pcid_interface is now in scope).
local/sources/base submodule pointer: updated to upstream commit
ddcd0870 (the pcid_interface env-var-reading commit).
Test totals: 58 tests across 4 crates, all passing.
§ 0.5 audit-no-stubs.py: 0 violations across 35 files.
Base submodule bump (6db0f481): hardware-correct DesignWare engine
(disable/program/enable ordering, abort-first polling, corrected SCL
timing, recovery, validation) and proper Intel LPSS PCI bring-up.
- iwlwifi candidate tables: remove the c-prefixed iwlmld series from
the current Mini-MVM candidate lists — the MVM transport cannot
drive MLD firmware, and selecting it would fail firmware boot
instead of falling back to a compatible image (review MAJOR). c-series
returns with the MLD op-mode (Phase 6/W). Fallback TOML chains no
longer mix MLD and MVM series.
- redbear-iwlwifi + redbear-wifictl candidate detection now probes
both the flat /lib/firmware/iwlwifi-* and the post-2026
/lib/firmware/intel/iwlwifi/ layouts (review MAJOR).
- plan doc: review-fix round recorded; precision fixes — amd-mp2-i2cd
remains registration-only until its mailbox engine lands, and the
system-quirk flags parse but have no consumers until Phase 5.
Validation: iwlwifi 8 + wifictl 21 tests pass, base cooks for
x86_64-unknown-redox.
- Bump submodule/base to the acpid AML-handler hardening (bounded stall,
mutex owner-check, static _PSS/_PSD/_CST/_CPC cache, panic-free scheme
path, observability). Proven NOT a regression: a mutex-only baseline
wedges identically under load in a 3/3 framebuffer-ground-truth test,
so the residual under-load boot wedge is head-of-line blocking in
initnsmgr, not acpid.
- Add local/docs/INITNSMGR-CONCURRENCY-DESIGN.md: the concrete
worker-offload design (Design A) that decouples the blocking openat
from the initnsmgr dispatch loop, plus Design B (kernel O_NONBLOCK +
deferred single-thread), a staged plan, and validation rules. Key
finding baked in: redox_rt's Mutex is a spinlock, so the cap_fd must be
resolved under a short lock and the openat run with the lock released.
- Update INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md with the acpid
hardening section (done vs the still-deferred #1 transport decoupling).
- Add local/patches/wip-initnsmgr/step1-send-refactor.patch: the
compiled-but-not-yet-boot-validated Step 1 (Rc<RefCell> -> Arc<Mutex>
Send refactor) of initnsmgr, saved durably. It is intentionally NOT in
the base gitlink: bootstrap is the earliest-boot component and this
must be boot-validated on an idle host (the current host is under heavy
external load) before landing. Steps 2-5 (worker bring-up) likewise
need an idle host.
Round-two integrations of the driver-manager migration's D-phase.
The policy loader is now active (the redbear-driver-policy package
now actually changes spawn_decision_gate behavior at runtime), the
--concurrent=N CLI flag enables the SMP worker pool, PciQuirkFlags
is wired into actual driver spawn (env vars to the child), and the
two C0 service files have been committed in the local/sources/base
submodule. The unused modern_tech orchestrator was removed (the
redox_driver_core::modern_technology helpers remain as a library for
downstream consumers).
driver-manager (16 tests, was 13):
- config.rs: PciQuirkFlags hints are now passed to the spawned child as
env vars (REDBEAR_DRIVER_PCI_IRQ_MODE=intx_or_msi, REDBEAR_DRIVER_DISABLE_ACCEL=1).
Adds blacklist_match() consult at probe time before spawn_decision_gate.
- main.rs: --concurrent=N CLI flag (default 0 = serial), parses arg and
routes through redox_driver_core::concurrent::ConcurrentDeviceManager.
Loads /etc/driver-manager.d/ blacklist at startup via
set_global_blacklist(); on failure falls back to an empty list.
- policy.rs: new file. BlacklistFile / BlacklistEntry TOML schema,
load_dir() reads .toml/.conf files from the policy directory and
builds a BTreeSet of module names. Missing directory returns empty
(opt-in). Tests cover missing / valid / invalid-file paths.
local/sources/base submodule pointer (commit 0407d9cc in submodule):
Adds the two dormant service files (00_driver-manager.service in
init.d/ and 40_driver-manager-initfs.service in init.initfs.d/).
Both are gated by ConditionPathExists=!/etc/driver-manager.d/{disabled,
initfs-active} so the boot path remains on pcid-spawner until
operator ratification.
redox-driver-core: unchanged library. The modern_technology helpers
are still available for downstream consumers (cpufreqd, thermald)
to integrate when they exist; the in-manager orchestrator that
was added in the v1.3 round has been removed because it wrote JSON
files that nothing read.
§ 0.5 audit-no-stubs.py: 0 violations across 34 files. 52 tests pass
across the three crates.
Base submodule bump (452452e4): the I2C transfer chain was stubbed
end-to-end and is now real code — dw-i2c DesignWare engine ported from
Linux 7.1, intel-lpss-i2cd PCI discovery for ARL-H/MTL-P, i2cd provider
routing.
Config fixes for the chain:
- drivers.d spawn paths: six entries pointed at /usr/lib/drivers/ for
binaries staged at /usr/bin/ (i2cd, gpiod, dw-acpi-i2cd, intel-gpiod,
i2c-gpio-expanderd, i2c-hidd) — those drivers would never spawn.
- init services: add 00_intel-lpss-i2cd.service
(type = { scheme = "i2c-lpss" }, absolute cmd path since init PATH
covers only /usr/bin); dw-acpi-i2cd upgraded from oneshot_async to
type = { scheme = "dw-acpi-i2c" } now that it serves a scheme
forever; i2c-hidd requires_weak gains 00_intel-lpss-i2cd.service so
the touchpad adapter exists before HID probing.
Validation: base cooks for x86_64-unknown-redox; staged binary paths
verified against spawn configs; make lint-config clean.
Refs: local/docs/LG-GRAM-16Z90TP-COMPATIBILITY-PLAN.md Phase 4
Systematic audit of all 18 scheme-serving daemons for the acpid failure
class (single-threaded daemon that can wait unboundedly in its serving
thread). Findings recorded in INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md:
- acpid was the ONLY software unbounded wait in the boot-critical path
(fixed). No other boot-path handler has an unbounded software wait or a
reentrant blocking open of another scheme.
- Hardware busy-waits (rtcd/ps2d/audio/gpu register polls) are
hardware-bounded or in daemons pcid does not spawn without the device.
- ucsid is the one remaining co-victim: it reads /scheme/acpi in
build_state() before publishing its scheme and is the only blocking,
acpi-dependent boot unit in redbear-mini. It already degrades on EAGAIN
and works with acpid fixed. It must NOT be flipped to oneshot_async
(that breaks ucsi scheme registration, which init performs via the
{scheme=…} type); the correct hardening is a source refactor
(publish-then-discover), done with runtime validation, not blind.
redbear-mini now reaches a working brush login and executes commands
(framebuffer ground truth: login -> MOTD -> `user@redbear: $` ->
`echo RB=$((21*2))=OK` -> `RB=42=OK`; login ~12s, brush ~16s in QEMU
q35/KVM). This is the console-login floor of the desktop path.
Root cause was NOT in login/brush/pty/spawn (16+ prior sessions chased
those). cpufreqd reads /scheme/acpi/processor/CPUn/pss; evaluating that
AML ran `_ACQ` on an ACPI mutex whose acquire handler (a) multiplied
the millisecond timeout by 1000 (0xFFFF "wait forever" became ~18h) and
(b) tracked no owner, so a nested acquire by acpid's single AML thread
self-deadlocked. Because acpid is single-threaded and also serves the
`acpi` scheme socket, and because the single-threaded init namespace
manager does a blocking openat in its dispatch loop, a stuck acpid
froze EVERY open in the system. Fixed in submodule/base d78fd44a
(bumped here), verified against local/reference/linux-7.1 ACPICA.
Docs:
- Add local/docs/INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md: the
residual architectural root (initnsmgr head-of-line blocking + kernel
ignoring O_NONBLOCK on open) that still lets one slow daemon wedge the
whole open path, with a worker-offload / deferred-open / kernel
O_NONBLOCK execution plan. This is the answer to "use SMP where it's
justified": the parallelism that matters is fault isolation of the
namespace-open path, not throughput.
- CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.9: record the mini-login result and
point at the new plan.
Note: submodule/base worktree also carries in-progress i2c/driver-manager
work (not part of this commit); the acpid fix is isolated.
Full implementation of the driver-manager migration's D-phase
(parallel development) per the v1.3 plan. The § 0.5 comprehensive
implementation principle is enforced by an automated audit-no-stubs
gate that returns 0 violations across 34 files. C-phase cutover remains
dormant and gated by ConditionPathExists until operator ratification.
redox-driver-core (28 unit + 5 integration tests):
- concurrent.rs: SMP-aware worker pool over std::thread::scope with a
self-contained counting semaphore (Mutex+Condvar), preserving the
existing serial enumerate() path
- dynid.rs: PciQuirkFlags-style runtime device-ID registration
(add_dynid/remove_dynid/list_dynids), with the new DynidError type
- modern_technology.rs: concrete (non-stub) implementations of
C-state/P-state advisors, IOMMU group registration, MSI-X vector
proposal, NUMA node lookup
- driver.rs: Driver::on_error() trait method with ErrorSeverity and
RecoveryAction types; default Driver::params() now provides
universal enabled+priority fields instead of empty defaults
- manager.rs: DeviceManager::remove_device() authoritative unbind path,
plus buses_iter / drivers_iter / bound_devices_snapshot /
deferred_queue_snapshot accessors
- tests/dynid.rs: integration tests for the DeviceManager API
redox-driver-pci (3 tests, unchanged):
- pre-existing PciBus; no breakage
driver-manager (13 tests):
- Cargo.toml: adds redox-driver-sys path dep
- quirks.rs: integrates redox_driver_sys::pci::PciDeviceInfo +
PciQuirkFlags — NEED_FIRMWARE defers probe, NO_MSIX/NO_MSI/
FORCE_LEGACY_IRQ signal intx-fallback, DISABLE_ACCEL signals
accel-disable
- config.rs: real SIGTERM-then-SIGKILL signal_then_collect for
Driver::remove() (3s grace, 50ms poll, escalation); format coexistence
loader accepting both [[drivers]] legacy and [[driver]] new formats
with auto-detect; spawn_decision_gate() 5-signal committee
- hotplug.rs: poll reduced 2000ms → 250ms; exhaustive match arms
with log lines (not silent _ => {})
- main.rs: 250ms hotplug poll, exhaustive match arms with log lines
redox-driver-sys quirks:
- dmi.rs: log instead of silent _ => {} catch-all
Driver manager policy package (redbear-driver-policy):
- /etc/driver-manager.d/00-blacklist.conf (4 driver blacklist entries)
- /etc/driver-manager.d/50-amdgpu.toml (AMD GPU driver policy)
- /etc/driver-manager.d/initfs.manifest (ordered initfs driver list)
- /etc/driver-manager.d/autoload.d/ntsync.conf (autoload ntsync module)
- /etc/driver-manager.d/README.md (explanation)
- recipe.toml: custom install script that stages into /etc/driver-manager.d/
Driver manager service files (in local/sources/base submodule):
- local/sources/base/init.d/00_driver-manager.service — dormant
(oneshot_async, ConditionPathExists=!/etc/driver-manager.d/disabled)
- local/sources/base/init.initfs.d/40_driver-manager-initfs.service —
dormant (oneshot, ConditionPathExists=!/etc/driver-manager.d/initfs-active)
Audit gate:
- local/scripts/driver-manager-audit-no-stubs.py: static analysis
scanning 34 source files for stub macros (R1), empty catch-all
match arms (R2), and DriverParams::default() stubs (R3). Returns
0 violations at v1.3.
- local/scripts/driver-manager-audit-no-stubs.sh: thin wrapper
- local/scripts/test-driver-manager-no-stubs-qemu.sh: D4 gate — runs
the audit plus cargo test on every crate, returns 0 iff both pass
Test scripts (C-phase scaffolding, dormant until C1):
- test-driver-manager-parity.sh (C1)
- test-driver-manager-active.sh (C3)
- test-driver-manager-initfs.sh (C2)
- test-driver-manager-hotplug.sh (D3)
- test-driver-manager-pm.sh (D2)
- test-driver-manager-cutover.sh (C4)
Docs:
- local/docs/DRIVER-MANAGER-MIGRATION-PLAN.md: v1.3 status table
listing every D-phase item as Done
- local/docs/evidence/driver-manager/D5-AUDIT.md: capability-by-
capability matrix + verbatim audit output
- local/docs/HARDWARE-VALIDATION-MATRIX.md: driver-manager rows
added with v1.3 status
- local/AGENTS.md: PLANNING NOTES pointer updated to v1.3
- docs/README.md: Related Red Bear-local plans row updated to v1.3
Test totals: 49 tests across the three crates, all passing.
Audit totals: 0 violations across 34 files, all clean.
Note: local/sources/base service files (00_driver-manager.service and
40_driver-manager-initfs.service) live in a submodule and need a
separate commit there. They are NOT included in this commit.
Same latent bug class as the acmd fix (f505d18a89): both drivers used
the USB endpoint ADDRESS number (ep.address & 0x0F) as the endpoint key,
but xhcid keys endpoints by global enumeration index across all
interfaces of the selected configuration. The two coincide only when
the device's endpoint addresses are sequential in enumeration order —
devices with non-sequential addresses (some modems/audio gear) would
open the wrong endpoint or fail to open.
Both now count endpoints in configuration order per selected
configuration, matching xhcid's PortState::get_endp_desc indexing.
Verified: cargo check -Z build-std --target x86_64-unknown-redox clean
for both crates.
Bug fix: endpoint numbers were computed as per-interface positions, but
xhcid keys endpoints by GLOBAL index across all interfaces of the
configuration. On two-interface ACM devices (comm interrupt-IN first),
the driver opened (interrupt-IN, bulk-IN) as (bulk_in, bulk_out) — read
from the interrupt endpoint and wrote to the IN endpoint. Endpoints are
now counted across all interfaces in configuration order, exactly as
xhcid's PortState::get_endp_desc does.
P6-A expansion (Linux 7.1 cdc-acm.c reference):
- SEND_BREAK (0x23) control request
- SERIAL_STATE monitoring: poll the comm interface's interrupt-IN
endpoint on a dedicated thread, parse the 8-byte header + 2-byte UART
state bitmap (CDC 1.1 6.3.5): DCD/DSR/break/RI/framing/parity/overrun,
log transitions
- scheme gains a read-only 'state' file reporting the current line
state (dcd=.. dsr=.. ...) for getty/terminal consumers
Verified: cargo check -Z build-std --target x86_64-unknown-redox clean,
no new warnings. Runtime validation needs an ACM device (QEMU has no
CDC ACM emulation; FTDI/Arduino on bare metal or passed through).
Upstream xhci_calculate_lpm_timeout needs SuperSpeed endpoint companion
SEL/PEL parsing across the hub tree + tier policy + XHCI_LPM_SUPPORT
vendor quirk. Defaults-only timeout writes would be speculative and can
break device links. P7-B assigned a dedicated workstream.
Audit: set_usb2_hw_lpm is xHCI-only upstream; EHCI PM is vendor-specific
TDI PHY LPM only. Correct EHCI power path is legacy L2 port suspend
(host-agnostic); deferred until a concrete device need arises.
base -> 2a3b0d4e: per-device USB 2.0 hardware LPM (L1) enablement at
attach in xhcid (full Linux xhci.c:4650 gate chain, BESL/HIRD params,
MEL Evaluate Context, PORTHLPMC/PORTPMSC sequence). Plan P7-A updated:
xhcid side done; ehcid USBCMD.HIRD and hardware L1 validation remain.
Bump base fork to 28afc1fe:
- ad40fffd ahcid: always re-arm the IRQ line, even for foreign interrupts
(from the UAS workstream)
- 92924224 e1000d/ihdad/vboxd/xhcid: unconditional ack
- 28afc1fe sb16d/ac97d/rtl8139d/rtl8168d/ixgbed/ihdgd: unconditional ack
- 54e89a33 fbcond: perform the display handoff open off the console loop
(concurrent session's root-cause fix for the '-vga std' boot freeze)
Bug class: kernel masks the IRQ line on delivery and only re-arms on the
userspace write-back; conditional acks wedged shared INTx lines forever.
Explains a class of 'works in QEMU, wedges on real hardware' failures.
Full audit + unaffected-driver rationale recorded in the IRQ plan P3
section.
The UHCI runtime proof grepped for the literal
'uhcid: controller initialized, polling ports'
but uhcid main.rs:535 emits it with ctrl.name interpolated mid-string:
info!("uhcid: {} controller initialized, polling ports", ctrl.name);
producing e.g. 'uhcid: 0000:00:01.2_uhci controller initialized, polling
ports'. The literal grep never matched and the proof would fail 100% of the
time at runtime.
Fix: grep with a regex anchored on the stable suffix:
grep -Eq 'uhcid: .* controller initialized, polling ports'
The ohcid, ehcid, usbhidd, and usbscsid markers were re-audited against
driver source and are all correct (ohcid main.rs:341 has no interpolation;
ehcid main.rs:294 interpolates after the matched comma prefix; all others
interpolate at line ends matched by prefix). Only the UHCI init-done marker
was broken.
Comment header and error echo updated to document the interpolated form and
point at main.rs:535 so the regex is not 'simplified' back to a literal.
No QEMU runs. bash -n passes. Verified the regex matches the real emitted
format and does not cross-match ohcid's identical suffix (the 'uhcid:' prefix
anchor disambiguates).
Create the four USB validation scripts that local/docs/USB-VALIDATION-RUNBOOK.md
references but which did not exist on disk, closing the P8-B runtime-proof gap
for the legacy host controllers and the P8-C error-injection gap for xHCI:
- test-uhci-runtime-qemu.sh (P1-B): -machine pc + piix3-usb-uhci, serial-log
proof that uhcid binds the controller and detects the attached usb-kbd.
- test-ohci-runtime-qemu.sh (P1-B): -machine pc + pci-ohci, serial-log proof
that ohcid binds the controller and detects the attached usb-kbd.
- test-ehci-class-autospawn-qemu.sh (P1-A): -machine q35 + usb-ehci + usb-kbd,
serial-log proof that ehcid enumerates the keyboard and usbhidd auto-spawns
via the unified UsbHostController trait. The existing test-ehci-qemu.sh is a
coarse usb-tablet smoke test and does NOT cover this path, so this is a full
script rather than an alias.
- test-usb-error-recovery-qemu.sh (P8-C): hot-unplug usb-storage mid-transfer
via the QEMU monitor device_del (chardev stdio mux, Ctrl-A c toggle — the
same pattern as test-xhci-device-lifecycle-qemu.sh, since qemu-login-expect.py
drives only serial and cannot reach the monitor). Proves graceful detach +
usbscsid IO-error handling with no panic.
test-xhci-device-lifecycle-qemu.sh already existed and is unchanged.
test-usb-uas-qemu.sh is intentionally NOT created: UAS is in flight in a
separate workstream and its test belongs to that change.
Proof style and harness fidelity:
- UHCI/OHCI/EHCI proofs follow the test-xhci-irq-qemu.sh serial-log grep
pattern (dual --check + interactive mode, ISO-preferred boot_args, 180s
timeout, no panic fail-marker). No guest-side checker exists that validates
legacy-controller enumeration specifically, so per the runbook's
serial-log-evidence rule they grep driver log lines instead of inventing a
guest binary.
- The error-recovery proof follows the test-xhci-device-lifecycle-qemu.sh
expect/Tcl monitor-mux pattern and reuses the existing redbear-usb-storage-check
guest binary (redbear-hwutils) to drive an active transfer — no new guest
binary is invented.
All proof markers are sourced directly from the real driver trees:
uhcid main.rs:487/535/545 (UHCI USB 1.1 at / controller initialized / connect)
ohcid main.rs:305/341/348 (OHCI USB 1.1 at / controller initialized / connect)
ehcid main.rs:154/294/560 (EHCI USB 2.0 at / controller initialized / port device)
usbhidd main.rs:221 (USB HID driver spawned with scheme)
usbscsid main.rs:190/200/163/156 (READ/WRITE IO ERROR / scheme tick / event error)
No existing scripts, qemu-login-expect.py, config/*.toml, recipes, or the
runbook were modified. The runbook's script names and --check invocations
already matched exactly, so no runbook edits were required.
Validation: bash -n passes on all four scripts. shellcheck is not installed on
this host. NO QEMU runs were performed — the host is contended by another
workload that kills QEMU processes, so validation is syntax check + pattern
fidelity review only. Runtime pass/fail is unverified.
Phases A-C static diagnosis of the wl_proxy_add_listener null+8 crash.
Evidence-backed root cause, candidate patch verdict, ruled-out hypothesis
cross-check, and a copy-pasteable instrumented-rebuild runbook for the
orchestrator.
Verdict: candidate patch qtwaylandscanner-null-guard-listeners.patch guards
the CORRECT site (every generated init_listener). Necessary but not
sufficient alone — complementary to libwayland redox.patch hunk 1.
v5.5 'verified FIXED' claim overstated: never tested in isolation,
kded6 workaround masked it, stale-sysroot risk documented.
Log-grep legs (MSI-X, xHCI IRQ) re-confirmed again this morning; login-based
legs still blocked by the concurrent .claude QEMU workload (SIGKILL of
competing guests); retry loop armed; IOMMU leg needs a redbear-full image.
Rebuilt cross-toolchain (clang/gcc/rust installs) following the relibc,
kernel, and base fork changes — stale prefix artifacts are the primary
cause of 'undefined reference' link errors after fork work. Tracked for
disaster recovery per 96e4a29592.
- 06-BUILD-SYSTEM-SETUP: note which QEMU proof scripts use
qemu-login-expect.py vs host expect
- 01-REDOX-ARCHITECTURE, LOCAL-FORK-SUPREMACY-POLICY,
SYSTEM-STABILITY-AND-UPSTREAM-SYNC-PLAN, UPSTREAM-SYNC-PROCEDURE:
sync with current fork-model and sync-procedure state
- Delete archived/SOURCE-ARCHIVAL-POLICY.md and
fork-push-status/2026-07-12-Round-5-phase-4.1.md — superseded by the
current local-fork model docs and newer fork-push-status rounds
- config/redbear-mini.toml: trailing newline
Enable GBM (required by the EGL/GBM/GLES2 surface used by Qt6/KWin).
Drop crocus/iris from the gallium driver set for the 26.1.4 build —
the Intel hardware drivers require DRM uapi surfaces that are not
available in the Redox sysroot yet. They MUST be restored when the
Intel DRM/redox-drm path matures (tracked in
local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md Stage 5); this is a
build-surface constraint, not a feature removal.
Also widen the -Wno-error set for the 26.1.4 cross-compile
(missing-prototypes, return-type, empty-body, incompatible-pointer-types,
int-conversion, format) — upstream Mesa enables -Werror by default and
the Redox sysroot headers trip these classes; the underlying warnings
remain visible in the build log.
Writing startup diagnostics to stderr interleaves with the interactive
console on the live image; /scheme/debug reaches the serial log without
disturbing the shell's tty.
On the live image, a fork/exec during login-shell startup can stall the
shell before its first prompt. Replace command substitutions with pure
builtins in the startup path:
- bash.bashrc: read /etc/redox_chroot with the 'read' builtin instead of
$(cat ...)
- profile: derive the root prompt from EUID/USER/LOGNAME (set by
login(1)) instead of $(id -u)
- skel/.bashrc: disable lesspipe and dircolors eval (both spawn
subprocesses); keep the ls --color=auto alias
base -> fb421083:
- fbcond: retry handoff while display driver is not ready (bounded
250x10ms; fixes the 2026-07-20 '-vga std' boot freeze at 'Performing
handoff' where a transient not-ready driver left the framebuffer VT
permanently blank)
- xhcid/virtio-netd: info-level IRQ/MSI-X delivery and reactor startup
milestones for runtime-proof observability
- usb: demote diagnostic ATTACH/HUBFLOW traces to debug!
- usbhubd: gate port-indicator SetPortFeature on hub capability
userutils -> 3b02e0b9:
- getty: harden the console<->PTY bridge against transient
read/write/event errors (log-and-continue instead of panic; a panic
here killed the live shell's I/O)
The kernel fork (submodule/kernel bd1b251f) now provides a proper
'install' target honoring DESTDIR, so the recipe no longer hand-rolls
the staging copy. Fork also gains post-merge compile fixes (import
dedup + UnmapVec).
Sync the tracked source tree to the wayland-protocols 1.49 release
tarball already pinned in recipe.toml (blake3-verified). Upstream 1.49
drops the pkg-config .pc.in files, switches scanner discovery to a
native wayland-scanner dependency with fallback, and adds the new
stable/staging protocol XMLs (ext-image-*, xdg-toplevel-icon,
cursor-shape, content-type, alpha-modifier, ...).
Convert the remaining expect-based test scripts (phase1-6 runtime, usb,
wifi, bluetooth, dbus, greeter, live-iso, posix) to the stdlib python
harness, completing the migration started in 9ec00d4c81. Each script now
prefers booting the live ISO when present (falling back to harddrive.img
with snapshot=on), and retries up to 5 times when QEMU exits early or is
killed (rc 3 / 137) — the host-contention failure mode recorded in the
2026-07-20 runtime-proof status.
qemu-login-expect.py: treat an incomplete step sequence as a failure even
when a pass marker was seen partway through — partial sequences must not
count as a pass.
Post-review fixes:
- Phase 2 no longer breaks early when only --fail_marker is set: the
'if not args.pass_marker: break' guard skipped all output reads, so a
fail marker was never detected (exit 0 instead of 1). Now breaks only
when neither pass nor fail markers are configured.
- docstring referenced --pass/--fail; argparse registers
--pass_marker/--fail_marker. Align the docstring.
- retry echo said 'attempt N/3' but the loop limit is 5 attempts; say /5.
- warn and skip malformed steps (missing expect:/send: prefix) instead of
spinning in select until timeout.
IRQ plan + validation matrix: the login-based QEMU proofs (PS/2 + serio,
monotonic timer, IOMMU first-use, USB storage BOT) now run through
local/scripts/qemu-login-expect.py (stdlib python) instead of the host expect
tool. MSI-X (virtio-net) and xHCI interrupt-driven mode were re-confirmed on
the current redbear-mini ISO. Re-confirmation of the login-based legs with the
new harness is pending an uncontended host (parallel QEMU workload kills QEMU
processes and stalls guest boots). Also record the fbcond Performing-handoff
boot freeze observed with -vga std (separate graphics-path issue).
Drop the host expect dependency from the PS/2, timer, IOMMU, and USB
storage (BOT) runtime proofs. local/scripts/qemu-login-expect.py drives
the guest over serial-on-stdio with ordered expect/send steps, per-step
timeouts (matching expect's per-pattern semantics), and pass/fail markers.
It distinguishes premature QEMU death (exit 3) from genuine check failure
(exit 1) so the scripts retry external interruptions without retrying real
failures. Scripts use headless -display none -vga none (fbcond serial
mirror), a 3600s per-step timeout, and a retry loop (max 5 attempts).
All six validation scripts (xhci-irq, msix, ps2, timer, iommu,
usb-storage) booted build/<arch>/<config>/harddrive.img, which is only
produced by older make-all flows and goes stale (the Jul-17 image).
Running them against it measured the wrong tree — the same trap that
produced the false '+rb0.3.0' bootloader reading and the first hub-test
failure. Each now prefers build/<arch>/<config>.iso via -cdrom and only
falls back to harddrive.img when no ISO exists. extra.img and
usb-storage.img remain as data drives in both modes.
Root cause of the duplication: a stalled migration. driver-manager (new
Red Bear framework) was written and packaged, but never wired in — its
00_driver-manager.service ran cmd="pcid-spawner" (the legacy binary),
and redbear-mini.toml already notes it is 'not yet ready'. Meanwhile the
base recipe's 00_pcid-spawner.service (oneshot_async) is the live
spawner. Both services ran pcid-spawner async, so pcid-spawner launched
TWICE in mini/full, racing to spawn the same drivers.
Consolidation (user directive: consolidate on pcid-spawner for now,
revisit driver-manager later):
- drop the unused driver-manager = {} package (source recipe kept for
the future migration),
- remove the duplicate 00_driver-manager.service,
- point 13_driver-params.service requires_weak at the real
00_pcid-spawner.service,
- base recipe's oneshot_async pcid-spawner is now the sole PCI driver
spawner — no more double launch.
driver-manager is intentionally left out of configs until its driver
config migration is completed (documented in the file).
Per-entry assessment (file was never deleted — no D commits in history;
continuously present, last touched Jul 16 by d5561184f0 which fixed
00_base.service zsh->mkdir and unblocked boot):
- KEEP 00_base.service (mkdir /tmp): base provides no 00_base.service;
the Jul-16 fix is the sole source and is required.
- REMOVE 20_audiod.service: redundant with base's identical oneshot_async.
- REMOVE zsh = {}: redundant with minimal.toml.
- REMOVE 00_pcid-spawner.service (type=oneshot): HARMFUL — the blocking
oneshot overrode the base recipe's fixed oneshot_async pcid-spawner,
re-introducing the boot-wedge the base recipe explicitly fixed. Base's
oneshot_async now wins (config /etc/init.d no longer shadows it).
Resolves the pcid-spawner service conflict (task T-7fdcd5e5).
Correct the P3-A runtime-validation note and matrix row: the
intermittent apparent boot freeze is startup latency under load (guest
clock ~10-15x slower than wall), not a deadlock or an xhcid bug. A short
50-60s test timeout occasionally cuts the spawn+enumerate sequence,
producing a 'frozen' log while the guest is still running — proven by
18 boots (one apparent short-timeout loss), a 12s log-quiet 'freeze'
the guest resumed from, and every >=180s run enumerating fully. No fix
required beyond adequate test timeouts; no speculative kernel-deadlock
fix was implemented.
The usb-kbd behind the QEMU usb-hub now enumerates fully: debounce ->
port reset -> enable -> second debounce -> pre-attach -> attach ->
ATTACH 5.2 -> slot 3 -> addressed -> descriptors read -> HID class match
-> 'Loading subdriver "USB HID" for port 5.2' (class 3.1 proto 1,
keyboard boot protocol).
Root cause of the final stall: an unconditional SetPortFeature
(PORT_INDICATOR) for every connected+enabled port NAK-hung on QEMU's
indicator-less hub (no control-transfer timeout), blocking the flow
before the post-enable debounce. Now gated on
wHubCharacteristics.HUB_CHAR_PORTIND like Linux has_indicators.
test-usb-hub-qemu.sh: check #5 now requires the hub-child subdriver
line ('Loading subdriver "USB HID" for port <root>.<child>') so a
root-port HID (tablet) can no longer satisfy it — closes a false-
positive hole. Timeout raised to 360s for slow TT-path driver bring-up.
Docs (plan P3-A runtime validation + matrix): full hub + hub-child
chain recorded as QEMU-proven; remaining items (intermittent reactor
startup race, slow TT-path Evaluate Context) noted.
vasilito