VirtualBox default VMs expose an AC'97 audio controller (8086:2415,
class 04/subclass 01) whose BAR0 is an I/O-space BAR. The IntelHDA
driver matched any Intel multimedia subclass, and ReadBar0 masked the
I/O BAR's port number into a bogus 'physical address' that MapMMIO
panicked on (non-page-aligned), halting boot.
Two fixes:
- IntelHDA now matches only subclass 0x03 (HD Audio); AC'97 (0x01) is
a different programming model and is not claimed.
- ReadBar0 returns 0 (no usable MMIO BAR) for I/O-space BARs instead
of handing a port number to MapMMIO.
Co-Authored-By: Claude Fable 5 <[email protected]>
Four fixes, each a root cause verified on hardware (AX211 + Bose QC Ultra):
1. Link Key Request Reply TRUNCATED: the pending-command queue's params
buffer was 16 bytes; the reply is 22 (addr 6 + key 16). The controller
got 10 key bytes -> every stored-key reconnection failed authentication
(status 5) since 2026-06-03 (0f16785). Fresh pairings never touch this
path, which kept the bug perfectly disguised as a headset quirk.
2. Secure Connections host support (0x0C7A) now enabled: bonds are minted
as P-256 (Type=7), interoperable with BlueZ's, and SC-bonded peers can
actually authenticate us.
3. Never write the BD_ADDR override (0xFC31) with the factory address:
it desyncs the firmware's crypto address from the on-air one and ALL
SSP pairing fails with status 5. (The spoofing feature itself was
already known-cosmetic: the baseband answers pages on the factory
address regardless.) import-bluez-bond.sh now removes the override.
4. A2DP channel setup: wait for Encryption Change before dialing L2CAP
(post-SSP sinks ignore unencrypted CONN_REQ), and LISTEN 2.5s first --
on reconnection the sink dials AVDTP itself and ignores our dials while
doing so. Ends the historical connRsp=FFFF retry-then-give-up failures.
Plus: queued security replies now log delivery + controller status.
Co-Authored-By: Claude Fable 5 <[email protected]>
- On Authentication Failure (Auth Complete status!=0 -- previously swallowed
silently -- or disconnect reason 0x05), drop the stale local link key so
the next connect falls back to fresh SSP pairing instead of failing
identically forever (BlueZ behavior). Log the link-key exchange.
- scripts/import-bluez-bond.sh: copy a BlueZ link key into the MontaukOS
key store on the installed root. Root cause: the AX211 BD_ADDR override
(0xFC31) is cosmetic -- the baseband answers pages on the FACTORY address,
so peers see Linux and MontaukOS as ONE device with ONE key slot, and each
OS's pairing clobbers the other's key. Sharing identity + key ends the
fight: both OSes reconnect (incl. autoconnect) without re-pairing.
Co-Authored-By: Claude Fable 5 <[email protected]>
The BT firmware download now runs from the idle loop after boot (zero boot
stall), completing the async goal. What made every earlier deferral attempt
fail was a months-latent HCI-layer bug, not the deferred environment:
WaitCommandComplete returned after the FIRST USB packet of an event, but
events larger than the 64-byte interrupt max-packet (like the AX211's
96-byte FC05 TLV version response) span several packets. Sending the next
command while the tail of the previous response was still in flight wedges
the AX211 bootloader into permanently ignoring commands. Boot-time flanterm
rendering added milliseconds between commands and accidentally paced the
protocol past the race -- which is why the synchronous bring-up always
worked and every log-suppressed (deferred) bring-up went mute at FC05 #2,
regardless of scheduling/MSI/xHCI fixes.
Fix: reassemble multi-packet Command Complete/Status events in the
transfer callback; the mailbox is marked ready only when the declared
event length has fully arrived. This inherently paces command flow and,
as a bonus, the TLV version read now sees the full response (sbe_type
present -> ECDSA/RSA selection is no longer a guess).
Also: per-slot EP0 completion tracking in the xHCI (a waiting ControlTransfer
can no longer be released early by another device's EP0 completion).
Verified on the AX211: instant boot, background download, real BD_ADDR.
Co-Authored-By: Claude Fable 5 <[email protected]>
Two fixes, verified on the AX211 (8087:0033), ibt-1040-0041.sfi, 720 KB:
1. TryHeader waited 1500+2000 ms for secure-send results after the CSS and
key/signature sends, but on success this controller stays SILENT until
the end of the whole download (traced) -- both timeouts always burned in
full. A rejection arrives within milliseconds, so 250 ms windows lose
nothing and save ~3 s per cold boot.
2. The payload now goes over the bulk OUT endpoint with up to 7 fragments
in flight (the btusb bootloader path for 0xFC09), replacing ~2900
synchronous 3-stage EP0 control transfers. Headers stay on EP0; the
ACL TX DMA ring is reused (no ACL header, no NOCP credit accounting).
DrainBulkTx() ensures all bytes reach the controller before waiting for
the download-complete result.
Also in this branch since main: IRQ-safe BT-TRACE ring (KernelLogStream in
TransferCallback deadlocked on the terminal Mutex from MSI context), xHCI
interrupt-IN ZLP length fix, always-re-arm of the BT event pipe,
InPollContext same-core owner check, TLV version read retry.
Co-Authored-By: Claude Fable 5 <[email protected]>
Deferring the Intel BT firmware download off the boot path made the AX211
bootloader stop answering after the first FC05; even the final synchronous
revert freezes boot, so one of the 'neutral' fixes kept in this diff breaks
the bring-up on its own (candidates: BT-TRACE logging inside TransferCallback,
unconditional interrupt-IN re-queue after error completions on a halted EP,
xHCI interrupt-IN ZLP len fix interacting with HID, InPollContext owner
check). Full history + next experiments in memory notes, 2026-07-05/06.
Co-Authored-By: Claude Fable 5 <[email protected]>
daniel
