Control: tags -1 + moreinfo Hi
On Fri, Oct 23, 2026 at 03:12:04PM -0700, Anna Smirnova wrote: > Package: linux-image-7.2.9+deb13-amd64 > Version: 7.2.9-1~bpo13+1 > Severity: important > Tags: upstream > > Dear Debian Kernel Team, > > I would like to report a reproducible Bluetooth regression affecting the > Realtek RTL8761BU USB Bluetooth adapter (USB ID 0bda) on Debian 13 (Trixie) > with the Linux 7.2.9 kernel from trixie-backports. > > Hardware and software environment > > - Host: nyrok-pc-lnx > - Distribution: Debian GNU/Linux 13 > - Affected kernel: 7.2.9+deb13-amd64 > - Affected package: 7.2.9-1~bpo13+1 > - Working kernel: 6.12.113+deb13-amd64 > - BlueZ: 5.82-1.1 > - Bluetooth adapter: Realtek RTL8761BU, USB 0bda > - Firmware: rtl_bt/rtl8761bu_fw.bin > - Firmware version: 0xdfc6d922 > - Bluetooth peripheral: Logitech MX Mechanical, Bluetooth LE HID (046d) > - Connection topology: USB adapter directly connected to xHCI root hub > > Observed behavior > > On Linux 7.2.9, the Bluetooth controller intermittently stops responding. > Following a system reboot, the Logitech MX Mechanical keyboard may fail to > reconnect automatically. > > Restarting the Bluetooth service temporarily restores normal operation. > > The following errors were recorded in the kernel log on October 23, 2026: > > Bluetooth: hci0: command 0x200c tx timeout > Bluetooth: hci0: Resetting usb device. > Bluetooth: hci0: Opcode 0x200c failed: -110 > Bluetooth: hci0: Unable to disable scanning: -110 > Bluetooth: hci0: Error when powering off device on rfkill (-110) > > After the reset, the adapter reinitializes as hci1, reloads the same > Realtek firmware, and the Logitech keyboard reconnects. > > Regression confirmation > > I installed and booted Debian’s 6.12.113 kernel on the same machine, using > the same Bluetooth adapter and keyboard. > > The issue does not reproduce with Linux 6.12.113. No Bluetooth pairing > changes or hardware replacement were necessary. > > Upstream investigation and proposed fix > > This behavior closely matches the known RTL8761BU regression associated > with HCI_QUIRK_BROKEN_EXT_SCAN. > > The following upstream fix appears directly applicable: > > Bluetooth: btusb: drop BROKEN_EXT_SCAN quirk for 0bda > > Commit: fdd5964bd389936856971647fcac3442117009dc > > https://git.kernel.org/bluetooth/bluetooth-next/c/fdd5964bd389 > > The patch was accepted into bluetooth-next on September 29, 2026. > > A closely matching regression, including the same USB ID, firmware version > and HCI timeout, is documented here: > > https://github.com/pop-os/pop/issues/4135 > > Request > > Could the Debian Kernel Team consider backporting the upstream fix to the > Linux 7.2 packages used by trixie-backports, or confirm which upcoming > Debian kernel package will include the correction? > > I can provide additional kernel logs and test a patched kernel or btusb > module if necessary. The above commit hash is not valid, but there is a matching upstream commit in mainline, df5e35f1663abc2702cf9f9e7eba024129ac5df1 . Can you confirm that applying the attached patch (test it with out debian/bin/test-patches script) fixes the issue? Instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 Can you plese test that? The commit is marked for stable, so will trickle in in net stable series updates as well. Regards, Salvatore
>From df5e35f1663abc2702cf9f9e7eba024129ac5df1 Mon Sep 17 00:00:00 2001 From: Junjie Cao <[email protected]> Date: Sun, 20 Sep 2026 10:02:27 +0800 Subject: [PATCH] Bluetooth: btusb: drop BROKEN_EXT_SCAN quirk for 0bda:a728 Commit 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") set HCI_QUIRK_BROKEN_EXT_SCAN on every RTL8761B, and commit ca0583c24661 ("Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728") kept it on 0bda:a728 on the assumption that the USB id separates dongles with broken extended scan from those with a broken legacy scan path. It does not. An 0bda:a728 unit (RTL8761BUV, fw 0xdfc6d922) on 6.18.51 fails the same way the UB500 and 0bda:8771 did: LE Set Scan Enable (0x200c) times out with -110 and btusb resets the device. With the flag removed from the table entry, scanning works on that unit. Two dongles with the same USB id need opposite settings, so the device table cannot key the quirk either. The costs are not symmetric. Without the quirk, the unit it was written for gets -EBUSY on LE Set Extended Scan Enable (0x2042) while a connection is up. With it, 0x200c times out and btusb resets the device on three reported units, two of them in a re-enumeration loop. Remove the flag and the table entry. 0bda:a728 matches the generic Realtek entry again and runs without the quirk, as before v7.2. Reported-by: Andy Tsvetinskiy <[email protected]> Closes: https://lore.kernel.org/all/cae4bxw+ofdfvx0athqcrzns9op1crqdm_wzeyhpembyohsp...@mail.gmail.com/ Fixes: 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") Fixes: ca0583c24661 ("Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728") Cc: [email protected] Signed-off-by: Junjie Cao <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> --- drivers/bluetooth/btusb_main.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c index cccdfb0461fe..3518f92ebbd3 100644 --- a/drivers/bluetooth/btusb_main.c +++ b/drivers/bluetooth/btusb_main.c @@ -70,7 +70,6 @@ static struct usb_driver btusb_driver; #define BTUSB_INTEL_NO_WBS_SUPPORT BIT(26) #define BTUSB_ACTIONS_SEMI BIT(27) #define BTUSB_BARROT BIT(28) -#define BTUSB_BROKEN_EXT_SCAN BIT(29) #define BTUSB_QUALCOMM BIT(30) static const struct usb_device_id btusb_table[] = { @@ -650,10 +649,6 @@ static const struct usb_device_id quirks_table[] = { { USB_DEVICE(0x0489, 0xe130), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, - /* Realtek 8761BU Bluetooth devices */ - { USB_DEVICE(0x0bda, 0xa728), .driver_info = BTUSB_REALTEK | - BTUSB_BROKEN_EXT_SCAN }, - /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), .driver_info = BTUSB_REALTEK }, @@ -4754,9 +4749,6 @@ static int btusb_probe(struct usb_interface *intf, if (id->driver_info & BTUSB_INVALID_LE_STATES) hci_set_quirk(hdev, HCI_QUIRK_BROKEN_LE_STATES); - if (id->driver_info & BTUSB_BROKEN_EXT_SCAN) - hci_set_quirk(hdev, HCI_QUIRK_BROKEN_EXT_SCAN); - if (id->driver_info & BTUSB_DIGIANSWER) { data->cmdreq_type = USB_TYPE_VENDOR; hci_set_quirk(hdev, HCI_QUIRK_RESET_ON_CLOSE); -- 2.55.0
