Bug 219365
| Summary: | USB bluetooth dongle stop working after upgrade from 6.11.1 to 6.11.2 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Adilson Dantas (adilson) |
| Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
| Status: | RESOLVED IMPLEMENTED | ||
| Severity: | normal | CC: | adilson, foliden163, luiz.dentz, pmenzel+bugzilla.kernel.org, regressions |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 6.11.2 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Trace usbmon file from a kernel without the fault commit.
Trace usbmon file from a kernel with the fault commit. |
||
Thank you for your report, and great that you can build the Linux kernel yourself.
> Maybe is one or all commits has caused the regression on my BT dongle
It’d be great if you tested each of the three commits. (Normally, `git bisect start -- drivers/bluetooth/btusb.c net/bluetooth/`, and then `git bisect good v6.11.1` and `git bisect bad v6.11.2`, would do that automatically.)
If you already have git clone, then:
git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
or, if you do not,
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Then
git reset --hard f68f72d04b60d3af36b63b888fe084966bca07b9
build and test. If it does *not* work, it’s the fault commit.
Then
git reset --hard 846a6fc7860119ee72737391856497b3fcf7c2b5
If it does *not* work, it’s the fault commit.
Then
git reset --hard 8603daa4300b84abb3c68e48f3b607d7d5a2a207
If it does *not* work, it’s the fault commit.
It’d be also good to know, if it works with current Linux master branch, or 6.12-rc2.
I tested each commit with 6.11.2 and 6.12-rc2 and I have isolated the regression at commit 8603daa4300b84abb3c68e48f3b607d7d5a2a207
Bluetooth: btusb: Fix not handling ZPL/short-transfer
[ Upstream commit 7b05933340f4490ef5b09e84d644d12484b05fdf ]
Reverting this commit fix the regression on my BT dongle.
(In reply to Paul Menzel from comment #1)
> Thank you for your report, and great that you can build the Linux kernel
> yourself.
>
> > Maybe is one or all commits has caused the regression on my BT dongle
>
> It’d be great if you tested each of the three commits. (Normally, `git
> bisect start -- drivers/bluetooth/btusb.c net/bluetooth/`, and then `git
> bisect good v6.11.1` and `git bisect bad v6.11.2`, would do that
> automatically.)
>
> If you already have git clone, then:
>
> git remote add stable
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> git fetch stable
>
> or, if you do not,
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>
> Then
>
> git reset --hard f68f72d04b60d3af36b63b888fe084966bca07b9
>
> build and test. If it does *not* work, it’s the fault commit.
>
> Then
>
> git reset --hard 846a6fc7860119ee72737391856497b3fcf7c2b5
>
> If it does *not* work, it’s the fault commit.
>
> Then
>
> git reset --hard 8603daa4300b84abb3c68e48f3b607d7d5a2a207
>
> If it does *not* work, it’s the fault commit.
>
> It’d be also good to know, if it works with current Linux master branch, or
> 6.12-rc2.
Thx for the bisection. As Paul mentioned earlier: "It’d be also good to know, if it works with current Linux master branch, or 6.12-rc2." I'd say it's not only "good to know", it's requires, as that determines whom we need to contact. (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #3) > Thx for the bisection. As Paul mentioned earlier: "It’d be also good to > know, if it works with current Linux master branch, or 6.12-rc2." I'd say > it's not only "good to know", it's requires, as that determines whom we need > to contact. I also tested with 6.12-rc2 and it is affected by this regression. Crap, looks like these old CSR dongle don't really handle the ZPL/sort-transfers, so we will likely need some workaround for these, most likely a new quirk. I guess we need to USB traces to check if that really what is at play since we are giving a bigger buffer to the USB stack perhaps it expecting the ZLP to finish the transfer but it never happens for some reason. Created attachment 306997 [details]
Trace usbmon file from a kernel without the fault commit.
Trace usbmon file from a kernel without the fault commit.
My BT dongle works fine when it is plugged
Created attachment 306998 [details]
Trace usbmon file from a kernel with the fault commit.
Trace usbmon file from a kernel with the fault commit.
My BT Dongle fails when it is plugged.
(In reply to Luiz Von Dentz from comment #6) > I guess we need to USB traces to check if that really what is at play since > we are giving a bigger buffer to the USB stack perhaps it expecting the ZLP > to finish the transfer but it never happens for some reason. I upload two traces from usbmon module. One from a kernel without the fault commit. So it is working fine. And another from a kernel with the fault commit. It fails when is plugged. I hope that theses files should help (In reply to Luiz Von Dentz from comment #10) > https://patchwork.kernel.org/project/bluetooth/patch/20241015153719.497388-1- > luiz.dentz@gmail.com/ I tested this patch with 6.11.3 and it worked with my BT dongle. Thanks. Closing it since this regression is resolved with kernel 6.11.5. (In reply to Luiz Von Dentz from comment #5) > Crap, looks like these old CSR dongle don't really handle the > ZPL/sort-transfers, so we will likely need some workaround for these, most > likely a new quirk. Same issue (with same BT adapter) after upgrade from 6.8.0-52 to 6.8.0-53 and/or 6.8.0-54 (Ubuntu 24.04 LTS, Linux Mint 22.1) |
After upgrading from 6.11.1 to 6.11.2, my bluetooth dongle stop working with the following errors below: 2024-10-09T01:29:45.564367-03:00 r2d2 kernel: usb 1-1: new full-speed USB device number 19 using xhci_hcd 2024-10-09T01:29:45.695468-03:00 r2d2 kernel: usb 1-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 2024-10-09T01:29:45.695539-03:00 r2d2 kernel: usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 2024-10-09T01:29:45.695557-03:00 r2d2 kernel: usb 1-1: Product: BT DONGLE10 2024-10-09T01:29:45.705487-03:00 r2d2 kernel: Bluetooth: hci1: CSR: Setting up dongle with HCI ver=6 rev=3120 2024-10-09T01:29:45.705563-03:00 r2d2 kernel: Bluetooth: hci1: LMP ver=6 subver=22bb; manufacturer=10 2024-10-09T01:29:45.705573-03:00 r2d2 kernel: Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once... 2024-10-09T01:29:45.705581-03:00 r2d2 kernel: Bluetooth: hci1: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround 2024-10-09T01:29:45.705588-03:00 r2d2 kernel: Bluetooth: hci1: HCI Delete Stored Link Key command is advertised, but not supported. 2024-10-09T01:29:45.705594-03:00 r2d2 kernel: Bluetooth: hci1: HCI Read Default Erroneous Data Reporting command is advertised, but not supported. 2024-10-09T01:29:45.705602-03:00 r2d2 kernel: Bluetooth: hci1: HCI Set Event Filter command not supported. 2024-10-09T01:29:45.716675-03:00 r2d2 systemd[1]: Starting systemd-rfkill.service - Load/Save RF Kill Switch Status... 2024-10-09T01:29:45.793744-03:00 r2d2 systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status. 2024-10-09T01:29:47.774485-03:00 r2d2 kernel: Bluetooth: hci1: Opcode 0x1004 failed: -110 2024-10-09T01:29:47.774559-03:00 r2d2 kernel: Bluetooth: hci1: command 0x1004 tx timeout 2024-10-09T01:29:50.804490-03:00 r2d2 systemd[1]: systemd-rfkill.service: Deactivated successfully. The dongle used: Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) It works fine under Windows and kernel 6.11.1 I have to copy the following files from 6.11.1 and rebuild the kernel to make the dongle work with 6.11.2 drivers/bluetooth/btusb.c include/net/bluetooth/hci_core.h net/bluetooth/hci_conn.c net/bluetooth/hci_sync.c net/bluetooth/mgmt.c Theses files were changed from the following commits between 6.11.1 and 6.11.2 5 days Bluetooth: btusb: Fix not handling ZPL/short-transfer Luiz Augusto von Dentz 1 -1/+4 [ Upstream commit 7b05933340f4490ef5b09e84d644d12484b05fdf ] Requesting transfers of the exact same size of wMaxPacketSize may result in ZPL/short-transfer since the USB stack cannot handle it as we are limiting the buffer size to be the same as wMaxPacketSize. Also, in terms of throughput this change has the same effect to interrupt endpoint as 290ba200815f "Bluetooth: Improve USB driver throughput by increasing the frame size" had for the bulk endpoint, so users of the advertisement bearer (e.g. BT Mesh) may benefit from this change. Fixes: 5e23b923da03 ("[Bluetooth] Add generic driver for Bluetooth USB devices") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by: Kiran K <kiran.k@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 5 days Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL Luiz Augusto von Dentz 1 -1/+4 [ Upstream commit cfbfeee61582e638770a1a10deef866c9adb38f5 ] This ignores errors from HCI_OP_REMOTE_NAME_REQ_CANCEL since it shouldn't interfere with the stopping of discovery and in certain conditions it seems to be failing. Link: https://github.com/bluez/bluez/issues/575 Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 5 days Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED Luiz Augusto von Dentz 3 -10/+13 [ Upstream commit d47da6bd4cfa982fe903f33423b9e2ec541e9496 ] If HCI_CONN_MGMT_CONNECTED has been set then the event shall be HCI_CONN_MGMT_DISCONNECTED. Fixes: b644ba336997 ("Bluetooth: Update device_connected and device_found events to latest API") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Maybe is one or all commits has caused the regression on my BT dongle