Bug 2521504
| Summary: | btusb: RTL8761BU enters infinite USB reset loop due to LE Set Scan Enable timeout — regression from 7.1.8 to 7.1.9 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sophian Zoeller <admin> |
| Component: | kernel | Assignee: | Justin M. Forbes <jforbes> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 44 | CC: | acaringi, adscvr, airlied, hans, hpa, jforbes, junjie.cao, kernel-maint, linville, mchehab, nickolasjcarr, ptalbert, steved, suraj.ghimire7 |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-7.1.13-200.fc44 kernel-7.1.13-100.fc43 | Doc Type: | --- |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-09-04 01:11:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sophian Zoeller
2026-08-22 16:09:06 UTC
The 7.1.8..7.1.9 window contains exactly two Bluetooth commits, both for
this chip:
781d944ca910 ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV")
- new device ID only
d5977f4f995e ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan")
- upstream 5ead2063611a, mainline since v7.2-rc1
The second one sets HCI_QUIRK_BROKEN_EXT_SCAN for every CHIP_ID_8761B
device, which makes the host switch from extended scan (0x2042) to the
legacy LE scan commands -- 0x200c, the exact opcode now timing out on
your adapter. It was written against an 0bda:a728 dongle where extended
scan was the broken half; on your unit the legacy path is evidently the
broken one, so the chip-wide quirk trades one failure for the other, and
the 0x200c timeout escalates into the USB reset loop you captured.
Two details would pin this down for the upstream report:
- the lsusb line for the dongle (vendor:product id), and
- the firmware/lmp lines from a working 7.1.8 boot:
dmesg | grep -iE 'hci0|rtl'
With those I will report it to linux-bluetooth and stable as a 7.1.9
regression and propose scoping the quirk by USB id or firmware version
instead of chip id. If you build kernels, reverting d5977f4f995e on top
of 7.1.9 is the quick local fix; booting 7.1.8 remains the workaround
otherwise.
Hello Junjie; USB device: Bus 001 Device 005: ID 2357:0604 TP-Link TP-Link UB500 Adapter Firmware/lmp lines from working 7.1.8-200.fc44.x86_64 boot: [ 205.643406] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 205.644401] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 205.645399] Bluetooth: hci0: RTL: btrtl_initialize: key id 0 [ 205.645401] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 205.648787] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 205.649437] Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210 [ 205.797420] Bluetooth: hci0: RTL: fw version 0xdfc6d922 [ 205.864482] Bluetooth: MGMT ver 1.23 On 7.1.8 the adapter initializes cleanly as hci0 and stays stable indefinitely. On 7.1.9 the same adapter loads firmware identically but hits the 0x200c timeout ~30 seconds later and enters the reset loop. Confirming this is a TP-Link UB500 (2357:0604) using the RTL8761BU chipset — so the quirk from d5977f4f995e is being applied chip-wide via CHIP_ID_8761B, but the legacy 0x200c scan path is the broken one on this unit rather than the extended scan (0x2042). Upstream fix posted, moving the quirk from the whole 8761B family to the 0bda:a728 dongle it was verified on, with your UB500 data as the regression evidence: https://lore.kernel.org/all/20260824053227.317496-1-junjie.cao@intel.com/ A Tested-by reply on that thread from your UB500 would help it land faster; either way it will reach Fedora through stable once merged. Fix is upstream: ca0583c24661 ("Bluetooth: btusb: limit RTL8761B
BROKEN_EXT_SCAN quirk to 0bda:a728"), merged in v7.3-rc1 via the
bluetooth for-net pull, Cc: stable. It moves the quirk from the chip-wide
btrtl switch to a btusb device-table flag on the 0bda:a728 dongle the
original workaround was written for, so your UB500 (2357:0604) goes back
to the 7.1.8 behaviour. Another 8761B user on the list (Kamil Serwus)
confirmed the same fix on his unit.
Fedora 44 backport so 7.1.y doesn't have to wait for stable:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4732
FEDORA-2026-a7b1ccd14c (kernel-7.1.13-100.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a7b1ccd14c FEDORA-2026-0d885c0533 (kernel-7.1.13-200.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-0d885c0533 FEDORA-2026-0d885c0533 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-0d885c0533` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0d885c0533 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2026-a7b1ccd14c has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a7b1ccd14c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a7b1ccd14c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2026-0d885c0533 (kernel-7.1.13-200.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2026-a7b1ccd14c (kernel-7.1.13-100.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report. |