New: btusb/btmtk: MT7921 BT audio fails after suspend/resume — stale ACL connection handle requires module reload to clear

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

Bug ID: 221707
Summary: btusb/btmtk: MT7921 BT audio fails after
suspend/resume — stale ACL connection handle requires module reload to clear
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Bluetooth
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Created attachment 310397
--> https://bugzilla.kernel.org/attachment.cgi?id=310397&action=edit
Attached: dmesg output (bt-dmesg.log) and lsusb -v + uname -a (bt-lsusb.log). dmesg confirms the reported issue and shows additional detail: alongside the recurring "ACL packet for unknown connection

System:
- Fedora 44, kernel 6.19.x
- BlueZ 5.86, PipeWire 1.6.7, WirePlumber 0.5.15
- Adapter: MediaTek MT7921, USB bus path 3-2
- Headset tested: Zebronics ZEB-THUNDER PRO (A2DP), MAC 41:42:09:03:43:EB

Symptom:
After suspend/resume, Bluetooth audio reconnects successfully but disconnects again within 2-3 seconds, every time, on every resume.

Root cause found:
The kernel log shows a recurring stale connection handle that survives every userspace-level recovery attempt:

kernel: Bluetooth: hci0: ACL packet for unknown connection handle 3837

This handle number persisted across all of the following recovery attempts, none of which fixed it:
- bluetoothctl disconnect / connect
- bluetoothctl remove + re-pair from scratch
- Power-cycling the headset itself
- rfkill block / unblock
- Full USB-level device de-authorize / re-authorize cycle (/sys/bus/usb/devices/3-2/authorized set to 0 then 1)

The only thing that cleared it was a full kernel module reload:

sudo systemctl stop bluetooth
sudo modprobe -r btusb btmtk
sleep 2
sudo modprobe btmtk
sudo modprobe btusb
sleep 5
sudo systemctl start bluetooth

After this, the headset reconnected and held the connection stably (verified over 2+ minutes of continuous audio playback, and across repeated suspend/resume cycles since).

Why this looks like a driver-level state bug rather than a BlueZ/userspace issue:
A full USB re-authorization cycle re-enumerates the device at the USB level, yet did not clear the stale handle. Only unloading and reloading the btusb/btmtk kernel modules did. This suggests the stale ACL connection handle is held in the driver's own internal HCI connection table state, surviving USB re-enumeration, and is only cleared on full module teardown/init.

Reproduction steps:
1. Pair an A2DP headset on a MediaTek MT7921 adapter.
2. Confirm a stable connection.
3. Suspend the system (systemctl suspend), then resume.
4. Observe: reconnect succeeds, then drops within ~2-3 seconds.
5. Run: dmesg | grep "unknown connection handle" — the same stale handle number reappears.
6. Confirm that only modprobe -r/modprobe of btusb and btmtk clears it; nothing else does.

I'm happy to test patches, provide additional dmesg/btmon captures, or run further diagnostics.

GitHub: https://github.com/sandeep11mahendrakar

You may reply to this email to add a comment.

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

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

sandeep mahendrakar ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |sandeepmahendrakar11@gmail.
                   |                            |com
     Kernel Version|                            |7.0.13-200.fc44.x86_64

You may reply to this email to add a comment.

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

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

Artem S. Tashkinov ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Artem S. Tashkinov ([email protected]) ---

*** This bug has been marked as a duplicate of bug 221706 ***

You may reply to this email to add a comment.

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