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.
vasilito
18c892a136