[Bug 220344] Intel AX211 bluetooth randomly disconnects and reconnects, started after kernel update

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220344

Christopher Trom (ctrom@trom.co) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ctrom@trom.co

--- Comment #9 from Christopher Trom (ctrom@trom.co) ---
Adding a data point - same symptoms on current software, with a couple of
workarounds ruled out.

SYSTEM

Hardware: Intel Wi-Fi 6E AX211 160MHz (CNVi combo WiFi/BT; BT enumerates as USB
8087:0033 via btusb/btintel)
Distro: Arch Linux
Kernel: 7.2.7-arch1-1
linux-firmware: 20260916-1 (current at time of testing)
Bluetooth modules: btusb, btintel (not btintel_pcie - BT side is USB-enumerated
despite WiFi being PCIe)
WiFi modules: iwlwifi, iwlmvm

Both kernel and firmware were current as of testing.

SYMPTOM

Same as OP: Bluetooth headphones disconnect, recovering automatically within a
couple of seconds. dmesg/journal shows:

kernel: Bluetooth: hci0: Hardware error 0x0c
kernel: Bluetooth: hci0: Retrieving Intel exception info failed (-16)

followed by bluetoothd/wireplumber/pipewire reporting the audio transport
failing and reconnecting:

wireplumber: pw.node: (bluez_output.<MAC>.1-XX) running -> error (Received
error event)
wireplumber: spa.bluez5: Failure in Bluetooth audio transport
/org/bluez/hci0/dev_<MAC>/fd0
bluetoothd: profiles/audio/avdtp.c:handle_unanswered_req() No reply to Suspend
request
bluetoothd: src/profile.c:ext_io_disconnected() Unable to get io data for
Hands-Free Voice gateway: getpeername: Transport endpoint is not connected
(107)

FREQUENCY / TIMING

Crashes recorded in one session (single boot), timestamps and gaps between
them:

21:21:40
21:29:17  (+7:37)
23:19:54  (separate session, same boot)
23:24:46  (+4:52)
23:30:36  (+5:50, no accompanying Hardware error - just a transport disconnect
w/ no crash)
23:35:34  (+4:58, no accompanying Hardware error)
23:37:17  (+1:43, + Hardware error)

No consistent period. Looked like it might be ~5 minutes for a stretch, but
that broke down (see the 1:43 gap).

THINGS I TRIED TO IDENTIFY A TRIGGER

1. WiFi AP roaming

Initially looked correlated (a crash followed a WiFi roam event by ~7s), since
this is a combo WiFi/BT chip. Pinned the NetworkManager WiFi connection to a
single AP's BSSID + 5GHz band to eliminate roaming entirely:

nmcli con modify <conn> 802-11-wireless.bssid <BSSID> 802-11-wireless.band a

Confirmed via nmcli con show that the pin was active and WiFi stayed on one
BSSID. A Hardware error 0x0c crash still occurred 3.5 minutes into a stable,
non-roaming WiFi connection, ruling out roaming as the (sole) trigger.

2. BT/WiFi coexistence + power-saving

Tried disabling hardware coexistence arbitration and power management via
modprobe options:

options iwlwifi bt_coex_active=0
options iwlwifi power_save=0
options iwlmvm power_scheme=1
options btusb enable_autosuspend=0

Rebuilt initramfs (mkinitcpio -P) and rebooted; verified all four parameters
took effect via /sys/module/*/parameters/*. A Hardware error 0x0c crash with
identical signature still occurred 3m20s after boot, with coexistence and
power-saving both disabled.

At this point the trigger doesn't appear to be WiFi-roaming-related or
coexistence/power-management-related. I'm open to suggestions on what else to
test (increased BT debug verbosity, btmon capture during a crash, etc.) if
useful for the bug report.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.