### System details

- Omarchy 3.8.5
- Lenovo IdeaPad 81D1 (BIOS 7XCN41WW), Intel Celeron N4000, 8 GB RAM
- Qualcomm Atheros QCA9377 combo card: Wi-Fi `168c:0042` (ath10k_pci), Bluetooth over USB `0cf3:e500` (btusb)
- Now: linux 7.2.3.arch1-3, bluez 5.87-2, pipewire 1.6.8, wireplumber 0.5.17, linux-firmware 20260810
- Before (no problem): linux 6.18.7.arch1-1, bluez 5.85, pipewire 1.4.10, wireplumber 0.5.13, linux-firmware 20260110
- All of these were upgraded together on 2026-09-12. First freeze on 2026-09-15.

### What's wrong?

After the update, connecting a Bluetooth headset (REDMI Buds 8 Lite) hard-freezes the whole machine about 2 minutes after the audio stream starts. The same headset worked on the same laptop before the update.

**Symptom**

- The whole machine stops in one second. Only holding the power button recovers it.
- Nothing is written to the kernel log.
- `kernel.softlockup_panic=1`, `kernel.nmi_watchdog=1` and `kernel.hardlockup_panic=1` were set. No panic screen appeared. In the last run the display went black at the moment of the freeze.
- It is not memory pressure: no swap in use, no OOM kills, load below 1.

**Steps to recreate**

1. Connect a Bluetooth headset that has a microphone (HFP/HSP capable).
2. Play any audio. Nothing else is needed.
3. Wait about 2 minutes.

**Timing**

- 7 freezes so far, every one shortly after a Bluetooth headset connect.
- I logged `/proc/interrupts` once per second with fsync. In the two runs captured this way, the machine died exactly 119 seconds after the stream started (18:38:37 to 18:40:36, and 18:52:54 to 18:54:53). Older freezes, measured from the journal: 95, 120 and 103 seconds.
- There is no interrupt storm. `xhci_hcd` stays flat at about 420 interrupts per second and `ath10k_pci` at about 77 per second until the last logged second.

**Workaround that stops it**

Making Bluetooth headsets playback only in WirePlumber (`~/.config/wireplumber/wireplumber.conf.d/`):

```
monitor.bluez.properties = {
  bluez5.roles = [ a2dp_sink a2dp_source ]
}

wireplumber.settings = {
  bluetooth.autoswitch-to-headset-profile = false
}
```

With this, the card only offers A2DP profiles, the `xhci_hcd` rate drops from about 420 to about 96 interrupts per second, and the same headset has now played for 18 minutes without a freeze (before: never more than 120 seconds). I will update this issue after longer use. The cost is that the headset microphone does not work.

So the hang seems tied to the HFP/HSP (SCO) side of `btusb` on kernel 7.x, not to A2DP. I do not have a kernel trace, so this part is a conclusion from the workaround, not a proven root cause.

**Things that did not help**

- Wi-Fi power save off (iwd `PowerSaveDisable=ath10k_pci`).

**Possibly related**

- #12379 (Bluetooth regression on kernel 7.2.x, different chip and different symptom)
- CachyOS forum: hard LOCKUP in `btusb_work -> __set_isoc_interface -> usb_set_interface -> xhci_urb_dequeue` on 7.0.x and 7.1.x when a headset voice (SCO) connection is set up or torn down, 6.18 LTS reported fine, same A2DP-only workaround: https://discuss.cachyos.org/t/recurring-hard-lockup-in-btusb-sco-path-set-isoc-interface-xhci-on-7-0-x-and-7-1-x-triggered-by-bluetooth-headset-mic/32090

This is most likely an upstream kernel regression, not an Omarchy bug. I am filing it here because other Omarchy users with a Bluetooth headset may hit the same hard freeze after updating, and the workaround above is small.