Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: After updating to kernel 7.1.9-200.fc44.x86_64, my RTL8761BU USB Bluetooth dongle enters an infinite crash loop. The LE Set Scan Enable command (opcode 0x200c) times out with -110 (ETIMEDOUT) approximately 30 seconds after firmware load, triggering a USB device reset. The adapter re-enumerates with a new hci index and the cycle repeats indefinitely. During this boot session, 382 firmware reloads were recorded. All Bluetooth peripherals (Logitech MX Master 3S, MX Keys S, Sony DualSense controller, Jabra Evolve 75) are unusable — they briefly connect then drop when the adapter resets. The HOG (HID over GATT) profile also fails with "Request attribute has encountered an unlikely error" on report descriptor reads during the brief windows the adapter is up. 2. What is the Version-Release number of the kernel: Broken: 7.1.9-200.fc44.x86_64 Working: 7.1.8-200.fc44.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes. Works on 7.1.8-200.fc44.x86_64, broken on 7.1.9-200.fc44.x86_64. 7.1.7-200.fc44.x86_64 was also working. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Boot with kernel 7.1.9-200.fc44.x86_64 on a system with an RTL8761BU USB Bluetooth dongle as the only Bluetooth adapter. The crash loop begins automatically within ~30 seconds of the adapter initializing. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: To verify: sudo dmesg | grep -c 'Bluetooth: hci.*RTL' 6. Are you running any modules that not shipped with directly Fedora's kernel?: NVIDIA proprietary driver (from RPM Fusion) 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
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.