### System details

- **Omarchy:** 4.0.4-1
- **Kernel:** linux-omarchy 7.2.5-3
- **Machine:** Beelink SER9 (AZW SER9), AMD Ryzen 7 255
- **Bluetooth:** Intel AX200NGW, USB `8087:0029` on `usb 1-5` (`btusb`). Wi-Fi on the same card (`iwlwifi` at `02:00.0`) stayed up.

### What's wrong?

**In one sentence:** when the Intel USB Bluetooth adapter fails firmware init, the Bluetooth panel is empty and **Update → Hardware → Bluetooth** (`omarchy restart bluetooth`) does nothing useful — it only unblocks rfkill. Reloading `btusb` brings the adapter back in about a second.

This looks like “Bluetooth is gone.” It is not switched off, and it is not missing hardware.

**What actually happened**

After a cold boot, BlueZ reported `No default controller available`. `bluetooth.service` was running, `rfkill` showed `hci0` unblocked, `/sys/class/bluetooth/hci0` existed, `lsusb` still showed `8087:0029`. Wi-Fi worked.

The kernel had already given up:

```text
Bluetooth: hci0: Reading Intel version command failed (-110)
```

`-110` is a command timeout. The AX200 Bluetooth side is a USB device that must upload firmware after a real power-off. That handshake timed out, leaving a zombie `hci0` that BlueZ will not use.

**What Omarchy does today**

`bin/omarchy-restart-bluetooth` is:

```bash
rfkill unblock bluetooth
rfkill list bluetooth
```

That is the right fix for “I turned Bluetooth off.” It cannot unstick firmware. I ran it twice; no change. Then:

```bash
sudo rmmod btusb
sudo modprobe btusb
```

Firmware `intel/ibt-20-1-3.sfi` loaded in ~1.4s, BlueZ had `Controller … [default]`, `Powered: yes`. No reboot.

**Suggested change**

After the existing rfkill unblock, if `bluetoothctl list` still has no `Controller`:

1. `modprobe -r btusb && modprobe btusb` (needs root; the menu path already runs in a privileged terminal).
2. Wait a few seconds for firmware.
3. If a controller appears, done. If the same `-110` is back, the current “still broken” state is honest.

**Who benefits**

Anyone with Intel USB Bluetooth (AX200 / AX201 / AX210 and similar, `8087:00xx`) after a cold boot or hard power-off — laptops and mini PCs, not only this Beelink. People whose adapter is merely rfkill-blocked still get the current unblock first and never hit the reload.

**Scope (small, Omarchy-owned)**

- `bin/omarchy-restart-bluetooth` only.

Optional follow-up, **not required** to close this: pin `power/control=on` for Intel BT USB IDs. That overlaps #12095 (`omarchy-usb-autosuspend.conf` is a no-op; Intel controllers still autosuspend). On this machine `usbcore.autosuspend` is still `2` and `8087:0029` is `control=auto`. A udev pin may reduce how often firmware init loses the race; it does not replace a restart path that can recover a zombie `hci0`.

Out of scope: CMOS reset when **Wi-Fi** is also dead (`iwlwifi` `CSR_RESET` / probe `-110`). That is board power / BIOS, a different failure. If Wi-Fi still works, do not send people to CLR CMOS.

**Steps to reproduce** (when the adapter is already wedged)

```bash
bluetoothctl list          # empty / no Controller
lsusb | grep 8087          # device still there
journalctl -b | grep -F 'Reading Intel version command failed'

omarchy restart bluetooth  # still no controller

sudo rmmod btusb && sudo modprobe btusb
sleep 3
bluetoothctl list          # Controller is back
```

**Related (different bugs)**

- #11365 — panel shows “No adapter” after you **intentionally** rfkill-off; UI hole, not firmware timeout.
- #12095 — shipped USB autosuspend setting never applies; BLE HID reconnect. Same Intel USB family, different symptom.

Happy to test a patched `omarchy-restart-bluetooth` on this AX200.