Re: [REGRESSION] RTL8761BU 0bda:a728: removing BROKEN_EXT_SCAN fixes 0x200c timeout

[Andy Tsvetinskiy]

7.3-rc4 checked, issue still exists

пт, 25 сент. 2026 г. в 12:05, Thorsten Leemhuis <regressions@xxxxxxxxxxxxx>:
>
> On 9/18/26 15:37, Thorsten Leemhuis wrote:
> > Lo!
> > On 9/18/26 11:21, Andy Tsvetinskiy wrote:
> >>
> >>    This report concerns USB ID 0bda:a728, not 0bda:8771.
> >>
> >>    I have a Realtek RTL8761BUV USB Bluetooth adapter:
> >>
> >>    - USB ID: 0bda:a728
> >>    - Product: Bluetooth 5.4 Radio
> >>    - Firmware: rtl_bt/rtl8761bu_fw.bin
> >>    - Firmware version: 0xdfc6d922
> >>    - Running kernel: 6.18.51-1-lts
> >>    - Distribution: Arch Linux
> >>
> >>    With the stock btusb driver, Bluetooth repeatedly failed with:
> >>
> >>        Bluetooth: hci0: command 0x200c tx timeout
> >>        Bluetooth: hci0: Opcode 0x200c failed: -110
> >>        Bluetooth: hci0: Unable to disable scanning: -110
> >>        Bluetooth: hci0: Resetting usb device.
> >>        usb 1-2.2: reset full-speed USB device
> >>        Bluetooth: hci0: unexpected event for opcode 0x200c
> >
> > Thx for the report. Just replying to bring a few people into the loop
> > that can help handling this: the Blutooth maintainers and developers
> > which were involved in ca0583c2466174 ("Bluetooth: btusb: limit RTL8761B
> > BROKEN_EXT_SCAN quirk to 0bda:a728") [v7.3-rc1] and 5ead2063611ae5
> > ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan")
> > [v7.2-rc1]. Ciao, Thorsten
>
> Hmm, seems nobody cares, so we need to go the next step: can you please
> test if latest mainline (7.3-rc4 or later) is affected to rule out that
> it's something specific to the stable series in question?
>
> Ciao, Thorsten
> >>    The firmware was loaded successfully:
> >>
> >>        Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
> >>        Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
> >>        Bluetooth: hci0: RTL: fw version 0xdfc6d922
> >>
> >>    The USB autosuspend setting was not the cause:
> >>
> >>        /sys/bus/usb/devices/1-2.2/power/autosuspend: -1
> >>
> >>    The current upstream fix ca0583c24661
> >>    ("Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728")
> >>    is already present in my kernel. It sets BTUSB_BROKEN_EXT_SCAN for 0bda:a728.
> >>
> >>    I tested the opposite change locally in drivers/bluetooth/btusb.c:
> >>
> >>        - { USB_DEVICE(0x0bda, 0xa728), .driver_info = BTUSB_REALTEK |
> >>        -                    BTUSB_BROKEN_EXT_SCAN },
> >>        + { USB_DEVICE(0x0bda, 0xa728), .driver_info = BTUSB_REALTEK },
> >>
> >>    After rebuilding and reloading the btusb module:
> >>
> >>        systemctl stop bluetooth
> >>        modprobe -r btusb
> >>        modprobe btusb
> >>        systemctl start bluetooth
> >>
> >>    Bluetooth scanning worked normally. A 20-second scan completed with:
> >>
> >>        Discovery started
> >>        Discovering: yes
> >>
> >>    After loading the patched module, no new occurrences of the
> >> following messages appeared:
> >>
> >>        Opcode 0x200c failed: -110
> >>        Opcode 0x2042 failed
> >>        command tx timeout
> >>        Unable to disable scanning
> >>        Resetting usb device
> >>
> >>    The patched driver is currently loaded and Bluetooth remains operational.
> >>
> >>    This suggests that different RTL8761BUV devices or firmware
> >> revisions using USB ID 0bda:a728 may require different scan quirks. On
> >> my device, keeping BTUSB_BROKEN_EXT_SCAN causes the legacy 0x200c
> >> command to
> >>  time out, while removing the quirk fixes the issue.
> >>
> >>    Relevant upstream reports:
> >>
> >>    https://linux-regtracking.leemhuis.info/regzbot/regression/lore/20260822141115.58815-1-kserwus@xxxxxxxxx/
> >>
> >>    https://bugzilla.redhat.com/show_bug.cgi?id=2521504
> >>
> >>    https://lkml.iu.edu/2608.2/12212.html
> >>
> >>    Please let me know if more logs, a full patch, or additional
> >> testing is needed.
> >>
> >
>


-- 
-- follow your dream...