Phase C of the ACPI fork-sync plan. Applies targeted gap fixes on top
of the synchronized fork foundation (commits 4f2a043 + ae57fe3).
Closes 4 of the 8 critical gaps identified by the 2026-06-30 ACPI
assessment.
Gap 5 - SLP_TYPb PM1b write (acpid/src/acpi.rs):
The previous code wrote SLP_EN+SLP_TYPa to PM1a but silently dropped
SLP_TYPb. On hardware that requires both PM1a and PM1b writes
(some laptops, server boards with split power blocks), the shutdown
was incomplete. Now writes SLP_EN+SLP_TYPb to PM1b when
pm1b_control_block is non-zero. The FADT field is 0 when no
second block exists, in which case we skip the second write.
Gap 6 - parse_lnk_irc range validation (hwd/src/backend/acpi.rs):
The previous code accepted any 16-bit integer as an IRQ
(n AND 0xFFFF), producing "Enabled at IRQ 53313" from misparsed
FieldUnit accessors on QEMU PIIX4. Now validates that the IRQ
value is 2047 or less (the maximum valid legacy-compatible IOAPIC
IRQ). Out-of-range values are debug-logged and skipped instead
of polluting the routing table. Also adds a 15-bit cap on the
Buffer-based IRQ bit extraction (was unchecked).
Gap 3 - AML mutex create/acquire/release (acpid/src/aml_physmem.rs):
The new gitlab acpi crate (Phase B bump) added proper Handler
trait methods for create_mutex, acquire, and release. The previous
implementation was three log debug stubs returning fake success,
which would silently corrupt AML state for any DSDT/SSDT that
uses Mutex. Now implements a real mutex table backed by
std::sync.Mutex of FxHashSet u32:
- create_mutex allocates a unique u32 handle from a counter
- acquire busy-waits with 1ms sleeps until the handle is free
or the AML timeout (multiplied by 1000 for ms to us conversion)
expires; returns AmlError::MutexAcquireTimeout on timeout
- release removes the handle from the held set
Gap 4a - set_global_s_state non-S5 explicit warning (acpid/src/acpi.rs):
The previous code silently returned early when called with any
state other than 5. Now emits a log warn with the requested
state, naming the missing dependencies (_PTS/_WAK AML evaluation,
P-state preservation, wakeup path). This converts a silent failure
into a diagnostic that is visible in the boot log.
Also includes drivers/acpid/src/dmi.rs:158 - convert e.errno
(private field) to e.errno() (method call). The libredox
Error struct changed its errno from a public field to a method
in a newer release; the DmiError::Map(syscall::error::Error)
construction was using the field-access form, which broke the
build against current libredox. This is a build-fix that the
prior dirty tree already had; included here to keep base
buildable.
Verified by: CI=1 ./local/scripts/build-redbear.sh redbear-mini
succeeded with exit 0. ISO at build/x86_64/redbear-mini.iso
(512 MB) at 2026-06-30 05:28.
Phase B of the ACPI fork-sync plan (local/docs/ACPI-FORK-SYNC-STRATEGY-2026-06-30.md).
Pairs with the kernel fork-sync commit 4f2a043.
Restores the base fork to match upstream Redox OS base master for the
ACPI userspace:
- Cargo.toml (workspace):
* Add acpi = { git = "...redox-os/acpi.git", branch = "redox-6.x" }
workspace dependency. The jackpot51/acpi GitHub fork was
deprecated in favor of the gitlab.redox-os.org fork that
tracks the redox-6.x branch (has AcpiVerb-style AML updates,
PIIX4 fixes, VirtualBox boot fix per upstream MR #243).
* Switch redox_syscall from crates.io 0.8.1 to a git ref of
gitlab.redox-os.org/redox-os/syscall.git, with [patch.crates-io]
redirecting crates.io consumers to the gitlab fork. The
crates.io 0.8.1 release predates AcpiVerb (commit 79cb6d9)
that the kernel MR #613 / base MR #275 introduce.
- drivers/acpid/Cargo.toml: acpi.workspace = true.
- drivers/amlserde/Cargo.toml: acpi.workspace = true.
- drivers/hwd/Cargo.toml: add redox_syscall.workspace = true
dependency. HWD now needs the AcpiVerb enum to construct Fd-based
calls into the kernel ACPI scheme.
- drivers/amlserde/src/lib.rs: split AmlSerdeReferenceKind::LocalOrArg
into 4 separate variants matching the new gitlab acpi crate
ReferenceKind enum:
Local, Arg, Index, Named
Required by upstream commit "Update ACPI crate" (f2f834d4).
- drivers/acpid/src/main.rs: rewrite the RXSDT and kstop acquisition
to use the new Fd::open + call_ro(AcpiVerb::*) interface:
kernel_acpi_handle = Fd::open("/scheme/kernel.acpi", O_CLOEXEC, 0)
rxsdt = kernel_acpi_handle.call_ro(buf, READ, &[ReadRxsdt])
shutdown_pipe = kernel_acpi_handle.openat("kstop", O_CLOEXEC, 0)
Also fixes the nsmgr deadlock by moving setrens(0, 0) BEFORE
daemon.ready() (upstream commit 9dd6901d).
- drivers/hwd/src/backend/acpi.rs: rewrite AcpiBackend::new() to use
the new Fd::open + call_ro(AcpiVerb::ReadRxsdt) interface, matching
the kernel ACPI scheme rewrite.
Verified by: CI=1 ./local/scripts/build-redbear.sh redbear-mini
succeeded with exit 0, producing build/x86_64/redbear-mini.iso
(512 MB) at 2026-06-30 04:54.
Both daemons previously produced no Info-level output on successful start,
making it impossible to confirm from the boot log whether ps2d and inputd
were actually alive. The kernel serial log shows no [INFO] ps2d: or [INFO]
inputd: lines during normal boot, leading operators to assume the input
stack was dead when in fact it was working.
This adds two log::info!() calls:
- ps2d main.rs: after daemon.ready(), log that ps2d has registered
its ProducerHandle and is listening on serio/0 (keyboard) and
serio/1 (mouse).
- inputd main.rs: after setup_logging, log that inputd has registered
scheme:input and is waiting for handles.
These are emitted only on the successful startup path; existing
.error!()/.warn!() calls continue to surface real failures. No behavior
change; no functional effect on input handling.
Several downstream crates (acpid for SMBIOS scanning, redox-drm, GPU
drivers) hold the physmap error in a map_err adapter. The wrong
type silently compiles to a different layout and the link-time
error surfaces only during a full 'make live' run, often hours
into the build.
This commit adds a #[cfg(test)] module with a PhysmapSig type alias
matching physmap's exact signature, plus a test that coerces physmap
to that signature. If physmap's error type drifts (e.g. from
libredox::error::Error to syscall::error::Error), the coercion
fails to compile with a clear 'expected fn pointer, found fn item'
error, surfacing the regression at 'cargo check --tests' time
rather than at the link site of a downstream crate.
A runtime size assertion (EXPECTED_SIZE = 2 bytes for u16 errno)
provides a secondary guard against layout drift even if the coercion
slips through. Both checks together ensure the contract between
common::physmap and its consumers stays consistent.
Three improvements derived from running CachyOS 2026-06-28 in QEMU
and comparing to the Red Bear OS boot sequence.
drivers/pcid/src/main.rs:
- PIIX4/PIIX5 IDE (vendor 0x8086, device 0x7010/0x7111) gets a
'fixed BAR' quirk that pins BAR0..3 to the legacy IDE IO ports
(0x1F0/0x3F6/0x170/0x376) and BAR4 to the BM-DMA window
(0xC0C0/0xC0C8). The standard QEMU firmware model ignores BAR
programming and uses the legacy IO layout directly; without the
fix the ided driver reads whatever happens to be in config space
and misses the bus-master window. Linux applies the same quirk in
drivers/ata/ata_piix.c.
- Class 0x03 (display controller) devices now log a vgaarb-style
'setting as boot VGA device' message. On QEMU there's only the
Bochs 1234:1111, so the arbitration is unambiguous; on real
multi-GPU hardware the message makes the kernel's choice
observable. Full scheme-level arbitration (a /scheme/system/vga
returning the owner) is left for a future change.
initfs/tools/Cargo.toml + initfs/tools/src/bin/loop_mnt.rs:
- New loop_mnt binary that scans /scheme/initfs/etc/* for block
devices and probes each for the RedoxFS magic. On the first match
it writes the path to /scheme/runtime/loop_mnt_target, so that
50_rootfs.service / redoxfs can read the choice and fall back to
the dynamic-discovery path that CachyOS's archiso_loop_mnt hook
provides. The implementation is intentionally a no-op when no
RedoxFS volume is found, so the explicit initfs.toml path remains
the source of truth on a normal boot.
init.initfs.d/45_loop_mnt.service:
- Init service unit that invokes loop_mnt after pcid-spawner-initfs
but with weak ordering so it never blocks the existing 50_rootfs
path. Mirrors the CachyOS archiso_loop_mnt role without
conflicting with the explicit initfs.toml flow.
recipes/core/base-initfs/recipe.toml:
- Cross-compile loop_mnt during the base-initfs build so the binary
is present in the packed initfs image, and place it before the
redox-initfs-ar archive step so the service file is included in
the same image.
thermald and redbear-upower read_dir /scheme/acpi/{thermal,power} to
enumerate ACPI _TZ zones and _PR power sources. The acpid scheme
returned EIO for these new directory variants, which std::fs::read_dir
interprets as 'the path is not a directory or doesn't exist' and
emits a warning.
Return Ok with no entries for Thermal/Power getdents so read_dir
sees an existing-but-empty directory and consumers gracefully fall
through to the empty-state path.
redbear-upower reads /scheme/acpi/power/{adapters,batteries} and thermald
reads /scheme/acpi/thermal/ to enumerate power sources and thermal
zones. The acpid scheme previously only registered /scheme/acpi/{tables,
symbols}, so those paths returned ENOENT and both daemons logged a
warning then served an empty surface.
Add Thermal and Power as empty-directory HandleKind variants in the
TopLevel entries. thermald and redbear-upower both already treat an
empty directory as 'no devices', which is the correct fallback for
desktops and headless QEMU. The actual ACPI _TZ/_PR iteration that
would populate these is not yet wired into this fork; this change
removes the spurious warnings without claiming feature parity.
daemon/src/lib.rs: Daemon::ready() previously called .unwrap() on the
init pipe write, causing a panic with BrokenPipe when init had already
closed its read end during the startup phase. Daemons like i2c-gpio-expanderd,
intel-gpiod, dw-acpi-i2cd, and i2c-hidd hit this in redbear-mini boots.
Now BrokenPipe is silently ignored — the daemon is operational regardless
of init's readiness tracking state.
drivers/usb/ucsid/src/main.rs and drivers/gpio/i2c-gpio-expanderd/src/main.rs:
read_i2c_control_response() returned an empty buffer (no I2C adapters
registered) and then tried ron::from_str('') which failed at 1:1 with
'Unexpected end of RON'. This produced false-positive warnings on every
boot where no I2C hardware is present. Now an empty/whitespace response
returns AdapterList(Vec::new()) gracefully.
Red Bear OS