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

[bugzilla-daemon@kernel.org]

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

            Bug ID: 221706
           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: linux-bluetooth@vger.kernel.org
          Reporter: sandeepmahendrakar11@gmail.com
        Regression: No

Created attachment 310396
  --> https://bugzilla.kernel.org/attachment.cgi?id=310396&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.