Please refer to previous revisions if you know what to do.
The patch proposed was merged into kernel in 5.8 release, but no longer working as of linux 5.11
Last active
December 19, 2023 00:56
-
-
Save nevack/6b36b82d715dc025163d9e9124840a07 to your computer and use it in GitHub Desktop.
[ARCHIVED] Fix for CSR Dongle 0a12:0001 ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Hi tried this script, but it gives below error
cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No such file or director
I checked there is no such directory and file.
I have Ubuntu 20.04 LTS with Kernel 5.4.0-42-generic. Then updated kernel to hoping that 5.8.2-050802-generic hoping by Bluetooth device will work with this .(As you mentioned this script is accepted in 5.7 and 5.8 version of kernel)
With new kernel 5.8.2-050802-generic, it detects logitech M337 mouse , but not able to configure. Then I tried above script and got error
cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No such file or director
Here is the output of some commands
lsusb -vvd 0a12:0001... gives bcdDevice 25.20
dmesg |grep 'CSR clone detected'
[ 75.420911] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[ 4880.814947] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[22664.573526] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[23268.855461] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
btmon -w my.log
Bluetooth monitor ver 5.54
= Note: Linux version 5.8.2-050802-generic (x86_64) 0.574027
= Note: Bluetooth subsystem version 2.22 0.574029
= New Index: 00:1A:7D:DA:71:10 (Primary,USB,hci0) [hci0] 0.574030
@ MGMT Open: bluetoothd (privileged) version 1.17 {0x0001} 0.574031
@ MGMT Open: btmon (privileged) version 1.17
hcidump -X
HCI sniffer - Bluetooth packet analyzer ver 5.53
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
I've also executed this script on Ubuntu 20 with latest update at the moment and exited with an error
==> Applying CSR dongle fix
patching file drivers/bluetooth/btusb.c
Hunk #1 succeeded at 1630 (offset -90 lines).
Hunk #2 succeeded at 1650 (offset -90 lines).
Hunk #3 succeeded at 3942 (offset -111 lines).
patching file include/net/bluetooth/bluetooth.h
patching file include/net/bluetooth/hci.h
Hunk #1 FAILED at 227.
1 out of 1 hunk FAILED -- saving rejects to file include/net/bluetooth/hci.h.rej
patching file net/bluetooth/hci_core.c
Hunk #1 succeeded at 605 (offset -1 lines).
Hunk #2 succeeded at 847 (offset -5 lines).
I've also executed this script on Ubuntu 20 with latest update at the moment and exited with an error
==> Applying CSR dongle fix patching file drivers/bluetooth/btusb.c Hunk #1 succeeded at 1630 (offset -90 lines). Hunk #2 succeeded at 1650 (offset -90 lines). Hunk #3 succeeded at 3942 (offset -111 lines). patching file include/net/bluetooth/bluetooth.h patching file include/net/bluetooth/hci.h Hunk #1 FAILED at 227. 1 out of 1 hunk FAILED -- saving rejects to file include/net/bluetooth/hci.h.rej patching file net/bluetooth/hci_core.c Hunk #1 succeeded at 605 (offset -1 lines). Hunk #2 succeeded at 847 (offset -5 lines).
Read https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3426618
I'm on Unbuntu 20 too. But i moved on official kernel 5.8.1-050801-generic with the patch . it works fine for me
Yes...finally it is working...
I installed kernel 5.8.3 and ran above script
And it is working...
Thank you very much....
Hi. That is an old kernel version; to backport the patch to older Linux versions remove the
HCI_QUIRK_BROKEN_ERR_DATA_REPORTINGline frombtusb.cand ignore thehci.h/hci_core.cchanges, as none of that had been implemented by then. After that it should work fine.
FYI, patch no longer works for at with kernel versions 5.8.3 and up (currently 5.8.5 on Arch).
FYI, patch no longer works for at with kernel versions 5.8.3 and up (currently 5.8.5 on Arch).
Well, Marcel merged the v4 of my patch and it got mainlined starting with the 5.8.2 stable kernel, and probably 5.9.
Take a look at the Bugzilla thread, I give progress updates.
There's a weird Bluetooth regression on my end when testing mainline 5.8.2+ where connections are buggy, not sure if other people can reproduce it. Kernel 5.7 with the same patch worked fine, so something must have been added in between that needs another workaround.
So yeah, any help helps.
Hi! Work with me only when i upgrade kernel to 5.8.3 from Ubuntu 20.04 LTS.
I Use mainline to upgrade the Kernel.
For Brazilians: https://medium.com/@lucasmacedo/instalando-usb-bluetooth-dongle-no-ubuntu-23c3378f83c3
Hi! I've patched the module for current ubuntu's kernel. I have two different dongles one of them works even without patch, other works only with enable_autosuspend=1 for some reason. Both of them work okay with my bluetooth speaker while there is some sound. But when sound ends and transmission stops, they seems to disconnect, and have trouble to connect automatically again when sound resumes. Is there any possible fix, or is that just bad dongles. Or maybe it has something to do with pulseaudio? I just want to know in what direction to look, because almost no information is found on this particular issue on google.
Hi! Work with me only when i upgrade kernel to 5.8.3 from Ubuntu 20.04 LTS.
I Use mainline to upgrade the Kernel.
For Brazilians: https://medium.com/@lucasmacedo/instalando-usb-bluetooth-dongle-no-ubuntu-23c3378f83c3
Did you also install the patch? or just updated the kernel? I tried just the kernel update but didnt work (perguntando porque é o que você disse no texto do medium)
Hi! Work with me only when i upgrade kernel to 5.8.3 from Ubuntu 20.04 LTS.
I Use mainline to upgrade the Kernel.
For Brazilians: https://medium.com/@lucasmacedo/instalando-usb-bluetooth-dongle-no-ubuntu-23c3378f83c3Did you also install the patch? or just updated the kernel? I tried just the kernel update but didnt work (perguntando porque é o que você disse no texto do medium)
Hello! I Just update the kernel, nothing else.
I am using Kernel 5.8.5. Bluetooth mouse is working fine, but some times it starts lagging and becomes very slow.Especially, when I start downloading files on Telegram, mouse becomes very slow. I tried some solutions , but problem is not solved.
Anybody know solution for this ?
Can confirm, 5.8.3 doesn't work properly, though patch is present. Kernel 5.8.8, on the other hand works correctly, also there is no disconnects. LED on a dongle keeps flashing all the time, so it seems they've added some fix to always transmit data to avoid disconnects.
The patch was the same. I guess our fake dongles are extremely finicky to little changes or new functionality they may be adding in BlueZ.
I don't have enough time to track down any Bluetooth issues anytime soon. So if anyone else rises to the challenge, it would be neat to get the other half working. Even narrowing down possible culprits may be helpful. You don't need to be a programmer.
sorry a newb here, where do I need to put this file in order to run the script?? do I use patch command?
sorry a newb here, where do I need to put this file in order to run the script?? do I use patch command?
Download all three files, and place them together.
Make .sh file executable and run it.
It's preferably to impicitly declare kernel version and extra as arguments.
For example, for kernel 5.8.9-arch1-1
./create_btusb_patch.sh 5.8.9 arch1-1
For kernel versions above 5.8.4 you don't need this patch, it's already included.
sorry a newb here, where do I need to put this file in order to run the script?? do I use patch command?
Download all three files, and place them together.
Make.shfile executable and run it.
It's preferably to impicitly declare kernel version and extra as arguments.For example, for kernel 5.8.9-arch1-1
./create_btusb_patch.sh 5.8.9 arch1-1For kernel versions above 5.8.4 you don't need this patch, it's already included.
Im running kernel 5.8.6 still cant use the btusb adapter properly it gets stuck scanning eternally. im still gonna try this fix thank you for answering!! I'll let you know what happens
Again, third time. I'm the patch author, this has been mainlined since Linux 5.8.2. If the kernel is newer you don't need this. The patch was a good first step back in Linux 5.7. But something they added after that has caused it to be insufficient.
We need more patches on top and I don't have time for that right now. So I'm asking for help.
Anyone with enough time can bisect and find the exact point where it stopped working. You don't need to be a developer to help, and it would help a lot.
guys it worked, i read something about usb 2 and usb 3, and i just swapped the ports and it worked, but very bad performance i have to say. thanks anyway, and my comment history got my journey.
How to run these codes in details? Every time I tried to run nothing happened :(
Got mine working on Mint 20 with kernel 5.7.19-050719-generic (from ubuntu mainline), patch is already applied, just download the .debs and install from: https://kernel.ubuntu.com/~kernel-ppa/mainline/
Btw, great job @Swyter and @nevack!
Bluetooth dongle:
Class: 0x0005a0
Service Classes: Unspecified
Device Class: Peripheral, Pointing device/(reserved)
HCI Version: 4.0 (0x6) Revision: 0x3120
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)
I typed on the terminal to apply on Ubuntu 20.04.1 with the Kernel: 5.8.2-050802-generic.
patch -p1 < fix_csr_dongle.patch, I got the following code:
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
|index 5f022e9cf..5b8cf9ba9 100644
|--- a/drivers/bluetooth/btusb.c
|+++ b/drivers/bluetooth/btusb.c
--------------------------
File to patch:
Skip this patch? [y] y
Skipping patch.
3 out of 3 hunks ignored
can't find file to patch at input line 111
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
|index 181900553..155019220 100644
|--- a/include/net/bluetooth/bluetooth.h
|+++ b/include/net/bluetooth/bluetooth.h
--------------------------
File to patch:
Skip this patch? [y] y
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 124
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
|index 16ab6ce87..1c321b6d1 100644
|--- a/include/net/bluetooth/hci.h
|+++ b/include/net/bluetooth/hci.h
--------------------------
File to patch:
Skip this patch? [y] y
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 146
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
|index dbe2d79f2..48d7c7e23 100644
|--- a/net/bluetooth/hci_core.c
|+++ b/net/bluetooth/hci_core.c
--------------------------
File to patch:
Skip this patch? [y] y
Skipping patch.
2 out of 2 hunks ignored
I got the similar problem about fix_btusb.patch. I need some helps to solve this problem.
I got the same problem on Kernel 5.8.1-050801-generic
I have this dongle and I am using 5.8.11 with Manjaro. The device gets detected but the problem is I can't search for any nearby devices, it's just empty. Also, my phone can detect the dongle but couldn't pair.
Edit: I think I have the 5.0 one with bcdDevice 25.20
I'm using v5.9.0 and my device is no more no being detectable. It was when using v5.4.0 and I was able to use it with my readmi airdots but not with my dualshock 4
btmon -w my.log
Bluetooth monitor ver 5.54
= Note: Linux version 5.9.0 (armv7l) 0.389794
= Note: Bluetooth subsystem version 2.22 0.389809
@ MGMT Open: bluetoothd (privileged) version 1.18 {0x0001} 0.389816
@ MGMT Open: btmon (privileged) version 1.18 {0x0002} 0.389977
@ RAW Open: hcitool (privileged) version 2.22 {0x0003} 29.538239
@ RAW Close: hcitool {0x0003} 29.538398
@ RAW Open: hcitool (privileged) version 2.22 {0x0003} 29.538529
@ RAW Close: hcitool {0x0003} 29.538556
lsusb -vvd 0a12:0001...| grep bcdDevice
bcdDevice 25.20
dmesg |grep 'CSR clone detected' returns nothing
hcidump -X
HCI sniffer - Bluetooth packet analyzer ver 5.54
Can't attach to device hci0. No such device(19)
sudo: mkinitcpio: command not found
For Brazilians, or anybody else, who bought a CSR 4.0 Dongle and Ubuntu users, the solution, based on the previous comments, was the following (at least for me):
First of all, identify your dongle id, by entering lsusb | egrep -i cambridge. If the output is Bus 002 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode), check the ID field. In this case, it is 0a12:0001.
Next, check your bcdDevice number by entering with lsusb -vvd 0a12:0001 | egrep -i bcdDevice. The output may be the number 25.20. If yes, nice, probably the next steps will work like a charm, if not, try it anyway, maybe could work.
- Updated the Kernel from 5.4.0-52 to 5.8.7 via offical Ubuntu kernel-ppa
- Installed blueman (and its dependencies)
- Tried to pair my bluetooth JBL T500BT sometimes, but without success... The workaround was to put the phone in pairing mode, search for it via blueman tool, click on "Configure", follow the wizard through pair step, after that, select "Headset" on connection step.
- Download the files attached on this gist, copy the .conf file to /etc/modprobe.d/ renaming the file from xxxx.conf to 99-xxx.conf.
Blueman says "No adapters found".
Blueman says "No adapters found".
What is your output for the lsusb command?
@pintoXD
Blueman says "No adapters found".What is your output for the lsusb command?
lsusb | egrep -i cambridge
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
and:
lsusb -vvd 0a12:0001 | egrep -i bcdDevice
Couldn't open device, some information will be missing bcdDevice 88.91
@pintoXD
Blueman says "No adapters found".What is your output for the lsusb command?
lsusb | egrep -i cambridge
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)and:
lsusb -vvd 0a12:0001 | egrep -i bcdDevice
Couldn't open device, some information will be missing bcdDevice 88.91
Well, that's weird... When it happens to me, I just unplug and plug again the dongle. What is your Kernel version?
Have you already took a look on the Arch Wiki's Bluetooth page? Maybe something there could help you.
Check it out : https://wiki.archlinux.org/index.php/Bluetooth#Bluetooth_USB_Dongle
I'm feeling stupid...
I managed to fix the script for working with namecdn=linux-"${3:-$(uname -r | cut -c"1,2,3,4,7,8")}".tar.xz and then another line a bit further to get make -C working with the correct name. So I passed that part.
Then I found that I had a bit older kernel 5.4.0-54-generic for which I needed to remove the HCI_QUIRK_BROKEN_ERR_DATA_REPORTING line from btusb.c and ignore the hci.h / hci_core.c patches.
I also had to install a dozen of packages, like make, gcc, flex, libssl-dev and probably some more.
But I am totally stuck on a very final part:
mkinitcpio: command not found
Nowhere can I find how or where to get mkinitcpio on my ubuntu machine.
IMPORTANT!!!
Before run the script (create_btusb_patch.sh) you may install the following dependencies:
sudo apt install flex bison
and be happy!
Yes...finally it is working...
I installed kernel 5.8.3 and ran above script
And it is working...
Thank you very much....
Thanks! It is working in my Kubuntu 20.04. I installed kernel 5.8.3 and the following dependencies:
sudo apt install flex bison
and after that the script (create_btusb_patch.sh) ran like a charm!
Hi,
Is it patched in kernel 5.9.9 - Linux Machine 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux ?
sudo bash ./create_btusb_patch.sh
==> Making patch for kernel 5.9.9
==> Removing temp files
==> Downloading kernel linux-5.9.9
--2020-11-30 22:25:36-- https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.9.9.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:46::432, 199.232.37.176
Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:46::432|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 115546864 (110M) [application/x-xz]
Saving to: ‘linux-5.9.9.tar.xz’
linux-5.9.9.tar.xz 100%[============================================================================>] 110.19M 11.7MB/s in 9.6s
2020-11-30 22:25:46 (11.4 MB/s) - ‘linux-5.9.9.tar.xz’ saved [115546864/115546864]
==> Extracting linux-5.9.9.tar.xz
==> Setting up kernel config
make: Entering directory '/home/user/Downloads/usb/linux-5.9.9'
make: Leaving directory '/home/user/Downloads/usb/linux-5.9.9'
make: Entering directory '/home/user/Downloads/usb/linux-5.9.9'
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
.config:7627:warning: symbol value 'm' invalid for ASHMEM
.config:8398:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC
*
* Restart config...
*
*
* Camera sensor devices
*
Hynix Hi-556 sensor support (VIDEO_HI556) [N/m/?] n
Sony IMX214 sensor support (VIDEO_IMX214) [N/m/?] n
Sony IMX219 sensor support (VIDEO_IMX219) [N/m/?] n
Sony IMX258 sensor support (VIDEO_IMX258) [N/m/?] n
Sony IMX274 sensor support (VIDEO_IMX274) [N/m/?] n
Sony IMX290 sensor support (VIDEO_IMX290) [N/m/?] n
Sony IMX319 sensor support (VIDEO_IMX319) [N/m/?] n
Sony IMX355 sensor support (VIDEO_IMX355) [N/m/?] n
OmniVision OV2640 sensor support (VIDEO_OV2640) [M/?] m
OmniVision OV2659 sensor support (VIDEO_OV2659) [N/m/?] n
OmniVision OV2680 sensor support (VIDEO_OV2680) [N/m/?] n
OmniVision OV2685 sensor support (VIDEO_OV2685) [N/m/?] n
OmniVision OV2740 sensor support (VIDEO_OV2740) [N/m/?] n
OmniVision OV5647 sensor support (VIDEO_OV5647) [N/m/?] n
OmniVision OV6650 sensor support (VIDEO_OV6650) [N/m/?] n
OmniVision OV5670 sensor support (VIDEO_OV5670) [N/m/?] n
OmniVision OV5675 sensor support (VIDEO_OV5675) [N/m/?] n
OmniVision OV5695 sensor support (VIDEO_OV5695) [N/m/?] n
OmniVision OV7251 sensor support (VIDEO_OV7251) [N/m/?] n
OmniVision OV772x sensor support (VIDEO_OV772X) [N/m/?] n
OmniVision OV7640 sensor support (VIDEO_OV7640) [N/m/?] n
OmniVision OV7670 sensor support (VIDEO_OV7670) [M/?] m
OmniVision OV7740 sensor support (VIDEO_OV7740) [N/m/?] n
OmniVision OV8856 sensor support (VIDEO_OV8856) [N/m/?] n
OmniVision OV9640 sensor support (VIDEO_OV9640) [N/m/?] n
OmniVision OV9650/OV9652 sensor support (VIDEO_OV9650) [N/m/?] n
OmniVision OV13858 sensor support (VIDEO_OV13858) [N/m/?] n
ST VS6624 sensor support (VIDEO_VS6624) [N/m/?] (NEW) n
mt9m001 support (VIDEO_MT9M001) [N/m/?] n
MT9M032 camera sensor support (VIDEO_MT9M032) [N/m/?] n
mt9m111, mt9m112 and mt9m131 support (VIDEO_MT9M111) [N/m/?] n
Aptina MT9P031 support (VIDEO_MT9P031) [N/m/?] n
Aptina MT9T001 support (VIDEO_MT9T001) [N/m/?] n
Aptina MT9T111/MT9T112 support (VIDEO_MT9T112) [N/m/?] n
Micron mt9v011 sensor support (VIDEO_MT9V011) [M/?] m
Micron MT9V032 sensor support (VIDEO_MT9V032) [N/m/?] n
Aptina MT9V111 sensor support (VIDEO_MT9V111) [N/m/?] n
Siliconfile SR030PC30 sensor support (VIDEO_SR030PC30) [M/n/?] m
Siliconfile NOON010PC30 sensor support (VIDEO_NOON010PC30) [M/n/?] m
Fujitsu M-5MOLS 8MP sensor support (VIDEO_M5MOLS) [N/m/?] n
IMI RDACM20 camera support (VIDEO_RDACM20) [N/m/?] n
Sharp RJ54N1CB0C sensor support (VIDEO_RJ54N1) [N/m/?] n
Samsung S5K6AAFX sensor support (VIDEO_S5K6AA) [N/m/?] n
Samsung S5K6A3 sensor support (VIDEO_S5K6A3) [N/m/?] n
Samsung S5K4ECGX sensor support (VIDEO_S5K4ECGX) [N/m/?] n
Samsung S5K5BAF sensor support (VIDEO_S5K5BAF) [N/m/?] n
SMIA++/SMIA sensor support (VIDEO_SMIAPP) [N/m/?] n
ET8EK8 camera sensor support (VIDEO_ET8EK8) [N/m/?] n
Samsung S5C73M3 sensor support (VIDEO_S5C73M3) [N/m/?] n
*
* Support for frame buffer devices
*
Support for frame buffer devices (FB) [Y/m/?] y
Enable firmware EDID (FIRMWARE_EDID) [Y/n/?] y
Enable Video Mode Handling Helpers (FB_MODE_HELPERS) [Y/?] y
Enable Tile Blitting Support (FB_TILEBLITTING) [Y/?] y
*
* Frame buffer hardware drivers
*
Cirrus Logic support (FB_CIRRUS) [M/n/y/?] m
Permedia2 support (FB_PM2) [M/n/y/?] m
enable FIFO disconnect feature (FB_PM2_FIFO_DISCONNECT) [Y/n/?] y
CyberPro 2000/2010/5000 support (FB_CYBER2000) [M/n/y/?] m
DDC for CyberPro support (FB_CYBER2000_DDC) [Y/n/?] y
Arc Monochrome LCD board support (FB_ARC) [M/n/y/?] m
Asiliant (Chips) 69000 display support (FB_ASILIANT) [N/y/?] n
IMS Twin Turbo display support (FB_IMSTT) [N/y/?] n
VGA 16-color graphics support (FB_VGA16) [M/n/y/?] m
Userspace VESA VGA graphics support (FB_UVESA) [M/n/y/?] m
VESA VGA graphics support (FB_VESA) [Y/n/?] y
EFI-based Framebuffer Support (FB_EFI) [Y/n/?] y
N411 Apollo/Hecuba devkit support (FB_N411) [M/n/y/?] m
Hercules mono graphics support (FB_HGA) [M/n/y/?] m
OpenCores VGA/LCD core 2.0 framebuffer support (FB_OPENCORES) [N/m/y/?] n
Epson S1D13XXX framebuffer support (FB_S1D13XXX) [N/m/y/?] n
nVidia Framebuffer Support (FB_NVIDIA) [N/m/y/?] (NEW) n
nVidia Riva support (FB_RIVA) [N/m/y/?] (NEW) n
Intel740 support (FB_I740) [N/m/y/?] n
Intel LE80578 (Vermilion) support (FB_LE80578) [M/n/y/?] m
Intel Carillo Ranch support (FB_CARILLO_RANCH) [M/n/?] m
Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support (FB_INTEL) [N/m/?] n
Matrox acceleration (FB_MATROX) [M/n/y/?] m
Millennium I/II support (FB_MATROX_MILLENIUM) [Y/n/?] y
Mystique support (FB_MATROX_MYSTIQUE) [Y/n/?] y
G100/G200/G400/G450/G550 support (FB_MATROX_G) [Y/n/?] y
Matrox I2C support (FB_MATROX_I2C) [M/n/?] m
G400 second head support (FB_MATROX_MAVEN) [M/n/?] m
ATI Radeon display support (FB_RADEON) [M/n/y/?] m
DDC/I2C for ATI Radeon support (FB_RADEON_I2C) [Y/n/?] y
Support for backlight control (FB_RADEON_BACKLIGHT) [Y/n/?] y
Lots of debug output from Radeon driver (FB_RADEON_DEBUG) [N/y/?] n
ATI Rage128 display support (FB_ATY128) [M/n/y/?] m
Support for backlight control (FB_ATY128_BACKLIGHT) [Y/n/?] y
ATI Mach64 display support (FB_ATY) [M/n/y/?] m
Mach64 CT/VT/GT/LT (incl. 3D RAGE) support (FB_ATY_CT) [Y/n/?] y
Mach64 generic LCD support (FB_ATY_GENERIC_LCD) [N/y/?] n
Mach64 GX support (FB_ATY_GX) [Y/n/?] y
Support for backlight control (FB_ATY_BACKLIGHT) [Y/n/?] y
S3 Trio/Virge support (FB_S3) [M/n/y/?] m
DDC for S3 support (FB_S3_DDC) [Y/n/?] y
S3 Savage support (FB_SAVAGE) [M/n/y/?] m
Enable DDC2 Support (FB_SAVAGE_I2C) [N/y/?] n
Enable Console Acceleration (FB_SAVAGE_ACCEL) [N/y/?] n
SiS/XGI display support (FB_SIS) [M/n/y/?] m
SiS 300 series support (FB_SIS_300) [Y/n/?] y
SiS 315/330/340 series and XGI support (FB_SIS_315) [Y/n/?] y
VIA UniChrome (Pro) and Chrome9 display support (FB_VIA) [M/n/y/?] m
direct hardware access via procfs (DEPRECATED)(DANGEROUS) (FB_VIA_DIRECT_PROCFS) [N/y/?] n
X server compatibility (FB_VIA_X_COMPATIBILITY) [Y/n/?] y
NeoMagic display support (FB_NEOMAGIC) [M/n/y/?] m
IMG Kyro support (FB_KYRO) [M/n/y/?] m
3Dfx Banshee/Voodoo3/Voodoo5 display support (FB_3DFX) [M/n/y/?] m
3Dfx Acceleration functions (FB_3DFX_ACCEL) [N/y/?] n
Enable DDC/I2C support (FB_3DFX_I2C) [Y/n/?] y
3Dfx Voodoo Graphics (sst1) support (FB_VOODOO1) [M/n/y/?] m
VIA VT8623 support (FB_VT8623) [M/n/y/?] m
Trident/CyberXXX/CyberBlade support (FB_TRIDENT) [M/n/y/?] m
ARK 2000PV support (FB_ARK) [M/n/y/?] m
Permedia3 support (FB_PM3) [M/n/y/?] m
Fujitsu carmine frame buffer support (FB_CARMINE) [N/m/y/?] n
SMSC UFX6000/7000 USB Framebuffer support (FB_SMSCUFX) [M/n/?] m
Displaylink USB Framebuffer support (FB_UDL) [M/n/?] m
Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors (FB_IBM_GXT4500) [N/m/y/?] n
Virtual Frame Buffer support (ONLY FOR TESTING!) (FB_VIRTUAL) [M/n/y/?] m
Xen virtual frame buffer support (XEN_FBDEV_FRONTEND) [Y/n/m/?] y
E-Ink Metronome/8track controller support (FB_METRONOME) [N/m/y/?] n
Fujitsu MB862xx GDC support (FB_MB862XX) [M/n/y/?] m
GDC variant
> 1. Carmine/Coral-P(A) GDC (FB_MB862XX_PCI_GDC)
choice[1]: 1
Support I2C bus on MB862XX GDC (FB_MB862XX_I2C) [Y/n/?] y
Microsoft Hyper-V Synthetic Video support (FB_HYPERV) [M/n/?] m
Simple framebuffer support (FB_SIMPLE) [N/y/?] n
Silicon Motion SM712 framebuffer support (FB_SM712) [N/m/y/?] n
*
* Android
*
Enable the Anonymous Shared Memory Subsystem (ASHMEM) [N/y/?] (NEW) n
*
* Android
*
Android Drivers (ANDROID) [Y/n/?] y
Android Binder IPC Driver (ANDROID_BINDER_IPC) [N/y/?] (NEW) n
*
* DOS/FAT/EXFAT/NT Filesystems
*
MSDOS fs support (MSDOS_FS) [M/n/y/?] m
VFAT (Windows-95) fs support (VFAT_FS) [M/n/y/?] m
Default codepage for FAT (FAT_DEFAULT_CODEPAGE) [437] 437
Default iocharset for FAT (FAT_DEFAULT_IOCHARSET) [ascii] ascii
Enable FAT UTF-8 option by default (FAT_DEFAULT_UTF8) [Y/n/?] y
exFAT filesystem support (EXFAT_FS) [M/n/y/?] m
Default iocharset for exFAT (EXFAT_DEFAULT_IOCHARSET) [utf8] utf8
NTFS file system support (NTFS_FS) [N/m/y/?] (NEW) n
#
# configuration written to .config
#
make: Leaving directory '/home/user/Downloads/usb/linux-5.9.9'
==> Applying CSR dongle fix
patching file drivers/bluetooth/btusb.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file drivers/bluetooth/btusb.c.rej
patching file include/net/bluetooth/bluetooth.h
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file include/net/bluetooth/bluetooth.h.rej
patching file include/net/bluetooth/hci.h
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file include/net/bluetooth/hci.h.rej
patching file net/bluetooth/hci_core.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file net/bluetooth/hci_core.c.rej
Any clue?
Yeah, it's included already, no need to patch kernel 5.9.9 - Linux Machine 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux
I had a look at source code and it's applied, but, for me, it's not working yet.
If I use only for listening, it works.
I have to use just one ear bud.
If I pair both ear buds it stops working and don't show me error in sudo btmon, or I couldn't find.
- btmon
btmon
> HCI Event: Disconnect Complete (0x05) plen 4 #713 [hci0] 1080.881629
Status: Success (0x00)
Handle: 0
Reason: Connection Terminated By Local Host (0x16)
> HCI Event: Disconnect Complete (0x05) plen 4 #714 [hci0] 1080.882621
Status: Success (0x00)
Handle: 48
Reason: Connection Terminated By Local Host (0x16)
- hcidump
> HCI Event: Connect Complete (0x03) plen 11
status 0x04 handle 0 bdaddr FF:FF:FF:FF:FF:FF type ACL encrypt 0x00
Error: Page Timeout
> HCI Event: Extended Inquiry Result (0x2f) plen 255
bdaddr 20:06:12:10:A9:BD mode 0 clkoffset 0x8349 class 0x240404 rssi -53
Complete local name: 'Mpow M9'
- dmesg
dmesg | grep Blue
[ 1204.318177] Bluetooth: hci0: command 0x041f tx timeout
[ 1206.334081] Bluetooth: hci0: command 0x0406 tx timeout
[94549.483072] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[94663.370221] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
My mic not working yet with this dongle.
Hi, I'm the patch author. Please take a look at my previous comments in this thread:
https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3456854
The patch is mainlined, but it was just a first step to get a bunch of these clones recognized and not a final solution. Unfortunately I've been busy since then and I'll probably won't be able to track this problem down and upstream the fix in a while.
So I recommend other people to give it a go and at least track down the Linux 5.7 regression. You won't see any fixes from official companies, Qualcomm is not interested in counterfeit dongles from what originally were CSR-branded chips that don't work that well with BlueZ.
The trick here is to find out what is Linux doing wrong here protocol-wise when on Windows they work normally.
Thank you Swyter, I appreciate your work!
I'm don't know how to debug yet, if you have some clue how to start I can try to help more.
Some info about BlueZ 5 support (A2DP only)
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/
Dropped HSP HFP support:
The support for BlueZ 5 has been gradually added in various applications, and this is the first PulseAudio version that supports BlueZ 5. This means that everything is great, right? Not so. The BlueZ project also decided to drop support for the HSP and HFP profiles, which were the profiles responsible for handling telephony audio. If you have a headset, its microphone won't work with BlueZ 5, because the microphone is only supported by the HSP and HFP profiles.
There are distributions that have migrated to BlueZ 5 without providing users the alternative of staying with BlueZ 4. Some of those distributions probably made the transition without understanding the consequences - they now have a serious regression in functionality, because their users' Bluetooth headsets have stopped working (well, the headsets can still be used for listening to music, but they're useless for VoIP applications).
GNOME made also a decision, possibly misinformed one, to drop support for BlueZ 4 in their last release, which means that upgrading to the current GNOME version (3.10) has one of two problems depending on the BlueZ version in the system: with BlueZ 4, the GNOME UI for managing Bluetooth won't work, and with BlueZ 5 the headset audio functionality will be crippled.
So what's the way forward with getting the HSP and HFP profiles work with BlueZ 5? There is partial support for those in oFono (a telephony daemon), which will hopefully be completed soon, and the next PulseAudio release will then hopefully support HSP/HFP through oFono. This pulls in a telephony stack as a dependency for using your Bluetooth headset, which might be considered overkill. This issue is yet to be resolved with the BlueZ developers.
So, or I try again (downgrade kernel / debian is not possible, so I need to reinstall everything) or wait.
I was in ubuntu 20.04. After updating to 20.10 and manually updating the kernel to the 5.8.3, I could run the script :-)
However, fails when trying to use
sudo mkinitcpio -p linux
Which is the alternative to this line on Ubuntu?
Thank you very much!
I was in ubuntu 20.04. After updating to 20.10 and manually updating the kernel to the 5.8.3, I could run the script :-)
However, fails when trying to use
sudo mkinitcpio -p linuxWhich is the alternative to this line on Ubuntu?
Thank you very much!
maybe update-initramfs -u ?
Guys...
I'm using Zorin OS based on Ubuntu, after a lot of hours trying make this device works I finally got this!!!!
Thanks to pintoXD your instructions worked for me:
1 - Update Kernel to 5.8.7
2 - Put csr-bluetoothdongle.conf into /etc/modprobe.d
3 - Be happy!
Another important problem with my hyperx USB sound card also was fixed after update to this kernel version....
Hi, I´ve been trying to install this patch on kernel 5.8.3 but then, the following error happened
Hi, I´ve been trying to install this patch on kernel 5.8.3 but then, the following error happened
sudo apt install flex
Hi, now I got this error
Hi, now I got this error
You're skipping the patchs, you need to apply.
Instead of -R use y
thank you for the help unfortunately this patch does not work on my computer even after finishing the process
Tks a lot, man!!! After 3 hours trying I finally get my fake dongle working with your patch!!!
For Ubuntu 20.04 users:
- Download and unpack the files above;
- Open the terminal in the folder and run:
sudo apt-get install flex bison --assume-yes - Open
create_btusb_patch.shand replace the lines
#!/usr/bin/env shto#!/usr/bin/env bashand
sudo mkinitcpio -p linuxtosudo update-initramfs -u - Go back to terminal and run
chmod u+x create_btusb_patch.sh - And finally
./create_btusb_patch.sh. - While the script runs it can ask you somethings during the kernel compilation, just type
nfor all of them. When it finishes, reboot your machine and enjoy!!
Edit: If after you run the script you receive a message with 404 error (what will happen with 5.8.0 version), you can download the kernel here, extract, rename to linux-5.8.0 and add a # to the following lines of the script:
info Downloading kernel $name
wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/$archive -O $archive
info Extracting $archive
tar -xJf $archive```
I'm facing a problem but with the latest kernel which i suppose has the included patch. 5.10.9-051009-generic
The problem is that right after binding the device, it disconnects.
dmesg error:
[ 199.016131] Bluetooth: HCI device and connection manager initialized
[ 199.016268] Bluetooth: HCI socket layer initialized
[ 199.016271] Bluetooth: L2CAP socket layer initialized
[ 199.016279] Bluetooth: SCO socket layer initialized
[ 199.086831] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[ 199.274426] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 199.274431] Bluetooth: BNEP filters: protocol multicast
[ 199.274440] Bluetooth: BNEP socket layer initialized
[ 199.445958] Bluetooth: RFCOMM TTY layer initialized
[ 199.445974] Bluetooth: RFCOMM socket layer initialized
[ 199.445987] Bluetooth: RFCOMM ver 1.11
[ 207.012831] Bluetooth: hci0: command 0x200c tx timeout
[ 207.012837] Bluetooth: hci0: failed to disable LE scan: status 0x1f
[ 220.967683] Bluetooth: hci0: command 0x200c tx timeout
[ 223.048102] Bluetooth: hci0: command 0x0405 tx timeout
[ 264.878204] Bluetooth: hci0: command 0x0408 tx timeout
[ 281.731795] Bluetooth: hci0: unexpected event for opcode 0x0000
doesn't work on 5.10.2-2
it is detected , but doesn't show any devices when scanning
tried on both usb 2 and 3 ports
$ uname -a
Linux hpc 5.10.2-2-MANJARO #1 SMP PREEMPT Tue Dec 22 08:14:42 UTC 2020 x86_64 GNU/Linux
[ 3121.298135] usb 1-11: new full-speed USB device number 7 using xhci_hcd
[ 3121.440174] usb 1-11: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=25.20
[ 3121.440181] usb 1-11: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 3121.440185] usb 1-11: Product: CSR8510 A10
[ 3121.443686] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
[ 3122.027853] audit: type=1130 audit(1611445734.946:127): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 3127.030940] audit: type=1131 audit(1611445739.949:128): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 3138.351375] Bluetooth: hci0: command 0x0401 tx timeout
thanks for you job, the script is very practice and functional, but on arch for default there aren't /usr/libmodules/$kernel/build directories, is necessary copy the .config from /proc/config.gz , extract and applicate and Module.symvers can ignored
Thank you for the job but, unfortunately, it did not work on Ubuntu 20.04 on Kernel 5.10.12.
I tried all the solutions above but I could not get success.
I am using one of the most common chinese dongles with CSR 5.0, exactly the one in this link
In all the operations, when I restart the system and verify the status of dongle I get:
hciconfig
hci0: Type: Primary Bus: USB
BD Address: 00:1A:7D:DA:71:12 ACL MTU: 679:8 SCO MTU: 48:16
DOWN
RX bytes:367 acl:0 sco:0 events:12 errors:0
TX bytes:37 acl:0 sco:0 commands:12 errors:0Which indicates the dongle was recognized but is not operating. Furthermore, I tried to make it up manually by sudo hciconfig hci0 up and again I could not activate the dongle getting the result: Can't init device hci0: Invalid argument (22)
Monitoring the Bluetooth with hcidump command when I tried to make the dongle UP with the above command I got:
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 4.0 (0x6) HCI Revision: 0x3120
LMP Version: 4.0 (0x6) LMP Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)
> HCI Event: Command Complete (0x0e) plen 4
Reset (0x03|0x0003) ncmd 1
status 0x00
> HCI Event: Command Complete (0x0e) plen 12
Read Local Supported Features (0x04|0x0003) ncmd 1
status 0x00
Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 4.0 (0x6) HCI Revision: 0x3120
LMP Version: 4.0 (0x6) LMP Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr 00:1A:7D:DA:71:12
> HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 1
status 0x00
ACL MTU 679:8 SCO MTU 48:16
> HCI Event: Command Complete (0x0e) plen 7
Read Class of Device (0x03|0x0023) ncmd 1
status 0x00 class 0x000000
> HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name 'CSR8510 A10.'
> HCI Event: Command Complete (0x0e) plen 6
Read Voice Setting (0x03|0x0025) ncmd 1
status 0x00 voice setting 0x0000
> HCI Event: Command Complete (0x0e) plen 5
Read Number of Supported IAC (0x03|0x0038) ncmd 1
> HCI Event: Command Complete (0x0e) plen 8
Read Current IAC LAP (0x03|0x0039) ncmd 1
IAC 0x9e8b33 (General Inquiry Access Code)
> HCI Event: Command Complete (0x0e) plen 4
Set Event Filter (0x03|0x0005) ncmd 1
status 0x12
Error: Invalid HCI Command ParametersFor this reason, I am asking for help since I am trying solutions to use the dongle on Linux for more than three weeks.
Since now, thank you for your help!
@Wanghley I think patch in upstream is outdated, as stated by initial author.
We should wait for new solution (or help with debugging).
It gets worse as those 5.0 labelled ones have the IC's identification wiped off.
A simple solution to Ubuntu 20.04 (Kernel: 5.3.0 or above)
(It works for me!)
- Create a file with the following line:
options btusb reset=1 enable_autosuspend=0
and save it as 99-csr-bluetoothdongle.conf
-
Copy that file to folder /etc/modprobe.d/ using the command line:
sudo mv 99-csr-bluetoothdongle.conf /etc/modprobe.d/ -
Restart Linux an enjoy your bluetooth dong!
@turtiustrek, my 5.0 labelled dongle have the IC's identification (but weird, Google didn't help) - UF9679
Hi,
First of all, thanks for all the work making this script in order to allow us to use this bluetooth on linux.
Using the script on kubuntu 20.10 with the kernel 5.8.3
i'm having this result:
○ → bash ./create_btusb_patch.sh
==> Making patch for kernel 5.8.3-050803-generic
==> Downloading kernel linux-5.8.3
--2021-02-04 10:58:48-- https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.3.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:2a::432, 151.101.177.176
Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:2a::432|:443... connected.
HTTP request sent, awaiting response... 416 Range Not Satisfiable
The file is already fully retrieved; nothing to do.
==> Extracting linux-5.8.3.tar.xz
==> Setting up kernel config
make: Entering directory '/home/higor/Desktop/linux-5.8.3'
CLEAN scripts/basic
CLEAN .config Module.symvers
make: Leaving directory '/home/higor/Desktop/linux-5.8.3'
make: Entering directory '/home/higor/Desktop/linux-5.8.3'
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
/bin/sh: 1: flex: not found
make[1]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127
make: *** [Makefile:606: oldconfig] Error 2
make: Leaving directory '/home/higor/Desktop/linux-5.8.3'
Can anyone help on this?
Tks a lot, man!!! After 3 hours trying I finally get my fake dongle working with your patch!!!
For Ubuntu 20.04 users:
- Download and unpack the files above;
- Open the terminal in the folder and run:
sudo apt-get install flex bison --assume-yes- Open
create_btusb_patch.shand replace the lines
#!/usr/bin/env shto#!/usr/bin/env bashand
sudo mkinitcpio -p linuxtosudo update-initramfs -u- Go back to terminal and run
chmod u+x create_btusb_patch.sh- And finally
./create_btusb_patch.sh.- While the script runs it can ask you somethings during the kernel compilation, just type
nfor all of them. When it finishes, reboot your machine and enjoy!!Edit: If after you run the script you receive a message with 404 error (what will happen with 5.8.0 version), you can download the kernel here, extract, rename to
linux-5.8.0and add a#to the following lines of the script:info Downloading kernel $name wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/$archive -O $archive info Extracting $archive tar -xJf $archive```
Thankssss! Worked perfectly for me on Pop!_OS 20.10!
Hi,
First of all, thanks for all the work making this script in order to allow us to use this bluetooth on linux.Using the script on kubuntu 20.10 with the kernel 5.8.3
i'm having this result:○ → bash ./create_btusb_patch.sh ==> Making patch for kernel 5.8.3-050803-generic ==> Downloading kernel linux-5.8.3 --2021-02-04 10:58:48-- https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.3.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:2a::432, 151.101.177.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:2a::432|:443... connected. HTTP request sent, awaiting response... 416 Range Not Satisfiable The file is already fully retrieved; nothing to do. ==> Extracting linux-5.8.3.tar.xz ==> Setting up kernel config make: Entering directory '/home/higor/Desktop/linux-5.8.3' CLEAN scripts/basic CLEAN .config Module.symvers make: Leaving directory '/home/higor/Desktop/linux-5.8.3' make: Entering directory '/home/higor/Desktop/linux-5.8.3' HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c /bin/sh: 1: flex: not found make[1]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127 make: *** [Makefile:606: oldconfig] Error 2 make: Leaving directory '/home/higor/Desktop/linux-5.8.3'Can anyone help on this?
A simple solution to Ubuntu 20.04 (Kernel: 5.3.0 or above) (Kubuntu, Xubuntu,etc)
(It works for me!)
Create a file with the following line:
options btusb reset=1 enable_autosuspend=0
and save it as 99-csr-bluetoothdongle.conf
Copy that file to folder /etc/modprobe.d/ using the command line:
sudo mv 99-csr-bluetoothdongle.conf /etc/modprobe.d/
Restart Linux an enjoy your bluetooth dong!
[in Portuguese] ---> If you are Brazilian or undestand this wonderful language...
À partir do kernel 5.3 do (Ubuntu 20.04 / Kubuntu /XUbuntu) basta fazer o seguinte procedimento:
- Crie um arquivo em um editor de textos com o seguinte conteúdo:
options btusb reset=1 enable_autosuspend=0
e salve-o com o nome 99-csr-bluetoothdongle.conf
(Curiosamente nomeá-lo apenas como csr-bluetoothdongle.conf não funcionou comigo. A única explicação é que adicionando os números na frente do nome o arquivo passa a ser o primeiro da lista na pasta /etc/modprobe.d/ após movê-lo para lá, é claro. Veja o ítem 2. Se isso for verdade, o nome poderia ser qualquer um, desde que na ordem alfabética fosse listado primeiro).
-
Em seguida, mova o arquivo para a pasta /etc/modprobe.d/ com o seguinte comando:
sudo mv 99-csr-bluetoothdongle.conf /etc/modprobe.d/ -
Não precisa nem reiniciar o computador, a partir de agora o seu Linux já poderá detectar novos devices bluetooth.
i tried all possible solutions and it didn't work, i'm on linux mint 20.1.
Kernel 5.8.3: "srjoao@srjoao-pc:~$ uname -r
5.8.3-050803-generic"
when I run the script it returns me to this output:
"==> Setting up kernel config
make: Entering directory '/etc/modprobe.d/linux-5.8.3'
make: Leaving directory '/etc/modprobe.d/linux-5.8.3'
cp: cannot stat '/usr/lib/modules/5.8.3-050803-generic/build/.config': No such file or directory"
can someone give me a light about of what i should do?
(translated in google translator)
Tks a lot, man!!! After 3 hours trying I finally get my fake dongle working with your patch!!!
For Ubuntu 20.04 users:
- Download and unpack the files above;
- Open the terminal in the folder and run:
sudo apt-get install flex bison --assume-yes- Open
create_btusb_patch.shand replace the lines
#!/usr/bin/env shto#!/usr/bin/env bashand
sudo mkinitcpio -p linuxtosudo update-initramfs -u- Go back to terminal and run
chmod u+x create_btusb_patch.sh- And finally
./create_btusb_patch.sh.- While the script runs it can ask you somethings during the kernel compilation, just type
nfor all of them. When it finishes, reboot your machine and enjoy!!Edit: If after you run the script you receive a message with 404 error (what will happen with 5.8.0 version), you can download the kernel here, extract, rename to
linux-5.8.0and add a#to the following lines of the script:info Downloading kernel $name wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/$archive -O $archive info Extracting $archive tar -xJf $archive```
libssl-dev is also required, so
sudo apt-get install flex bison libssl-dev --assume-yes
HAhHhahahahah It WORKS for me on Xubuntu 20.04 with kernel 5.11.0!!
I use this instruction:
- Download and unpack the files above;
- Open the terminal in the folder and run:
sudo apt-get install flex bison libssl-dev --assume-yes - Open create_btusb_patch.sh and replace the lines
#!/usr/bin/env sh to #!/usr/bin/env bash and
sudo mkinitcpio -p linux to sudo update-initramfs -u - Go back to terminal and run chmod u+x create_btusb_patch.sh
- Of course it needs commenting following lines (because the script you receive a message with 404 error, I downloaded the kernel from kernel.org, extract in script folder, rename to linux-5.11.0 and add a # to the following lines):
"
info Downloading kernel $name
wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/$archive -O $archive
info Extracting $archive
tar -xJf $archive```
" - And finally ./create_btusb_patch.sh.
While the script runs it can ask you somethings during the kernel compilation, just type n for all of them. When it finishes, reboot your machine and enjoy!!
Big thanks for all! I finally can use my headphones)))))
- Create a file with the following line:
options btusb reset=1 enable_autosuspend=0and save it as 99-csr-bluetoothdongle.conf
- Copy that file to folder /etc/modprobe.d/ using the command line:
sudo mv 99-csr-bluetoothdongle.conf /etc/modprobe.d/- Restart Linux an enjoy your bluetooth dong!
it's work for me, thank you @bennehcarvalho
Thanks, @nevack @bennehcarvalho
You guys, just saved my day.
@Wanghley I ran into same problem with 5.0. Have you find any solution?
@Wanghley I think one solution is revert the linux kernel source code to the July of 2020 and then apply patch again ✌️
i tried all possible solutions and it didn't work, i'm on linux mint 20.1.
Kernel 5.8.3: "srjoao@srjoao-pc:~$ uname -r
5.8.3-050803-generic"when I run the script it returns me to this output:
"==> Setting up kernel config
make: Entering directory '/etc/modprobe.d/linux-5.8.3'
make: Leaving directory '/etc/modprobe.d/linux-5.8.3'
cp: cannot stat '/usr/lib/modules/5.8.3-050803-generic/build/.config': No such file or directory"can someone give me a light about of what i should do?
(translated in google translator)
@Srjoao Try to look for modules directory in /lib instead of /usr/lib. Considering you are using mint, I highly doubt that this fix will work for you. I made it work on Ubuntu 20 after failing on 18.04.
I was using Ubuntu 18.04 and I faced the same problem. My modules directory was at /lib/. In case your modules directory exists at /etc/lib then what might help you is to install the 5.8.3-050803-generic.
I'll try to downgrade the kernel to 5.8.3 so we could apply patch, but it didn't work.
i tried all possible solutions and it didn't work, i'm on linux mint 20.1.
Kernel 5.8.3: "srjoao@srjoao-pc:~$ uname -r
5.8.3-050803-generic"
when I run the script it returns me to this output:
"==> Setting up kernel config
make: Entering directory '/etc/modprobe.d/linux-5.8.3'
make: Leaving directory '/etc/modprobe.d/linux-5.8.3'
cp: cannot stat '/usr/lib/modules/5.8.3-050803-generic/build/.config': No such file or directory"
can someone give me a light about of what i should do?
(translated in google translator)@Srjoao Try to look for modules directory in /lib instead of /usr/lib. Considering you are using mint, I highly doubt that this fix will work for you. I made it work on Ubuntu 20 after failing on 18.04.
I was using Ubuntu 18.04 and I faced the same problem. My modules directory was at /lib/. In case your modules directory exists at /etc/lib then what might help you is to install the 5.8.3-050803-generic.
thank you, with that the script was executed without error, but the dongle still does not work on linux :'(
After installing this patch, the Bluetooth adapter is not detected
After installing this patch, the Bluetooth adapter is not detected
Patch no longer works. Archived the gist.
After installing this patch, the Bluetooth adapter is not detected
Patch no longer works. Archived the gist.
There's no workaround to make it work anymore?
BlueZ keeps changing and adding features that make our dongles unresponsive. My mainlined patch probably detects the fake dongle, but someone needs to find some time to track down, test and apply the correct quirks. Check out the Bugzilla comment thread for hints.
I'm still busy, so I can't look into it. But submitting patches was an interesting learning experience. Hopefully you or someone else follows up.
So there's no way of making a bluetooth dongle work right now? Is it a bluez issue or a kernel issue?
A mix of both. If the dongles work on Windows is because the detection code and features are different.
If anyone still wants to use it, I found a way to make it work.
-
First you need to use an old kernel version. I'm using arch linux so I installed the LTS version:
sudo pacman -S linux-lts -
Then you need to downgrade
bluezalso. I'm using version5.56which the source code can be downloaded here. To install it run these commands:
- extract files
- cd into directory
- run
./configure - run
make - run
sudo make install
- Don't foget to set the modprode configuration:
sudo echo "options btusb reset=1 enable_autosuspend=0" >> /etc/modprobe.d/99-csr-bluetoothdongle.conf
After that, restart the system and pick the LTS kernel which is version 5.10.34-1-lts.
I tried before with newer kernels like version 5.11, 5.12 and I think they don't work at all. But it's still valid to try again, so if anyone could make it work on newer kernels, please tell me.
note: it was not needed to apply any patch, even for kernels on version 5.10.
EDIT
I tried again with the newest 5.12 kernels and it's still working, I just didn't tried on a fresh install without kernel v5.10
If anyone still wants to use it, I found a way to make it work.
1. First you need to use an old kernel version. I'm using arch linux so I installed the LTS version: `sudo pacman -S linux-lts` 2. Then you need to downgrade `bluez` also. I'm using version `5.56` which the source code can be downloaded [here](http://www.bluez.org/release-of-bluez-5-56/). To install it run these commands: * extract files * cd into directory * run `./configure` * run `make` * run `sudo make install` 1. Don't foget to set the modprode configuration: `sudo echo "options btusb reset=1 enable_autosuspend=0" >> /etc/modprobe.d/99-csr-bluetoothdongle.conf`After that, restart the system and pick the LTS kernel which is version
5.10.34-1-lts.I tried before with newer kernels like version 5.11, 5.12 and I think they don't work at all. But it's still valid to try again, so if anyone could make it work on newer kernels, please tell me.
note: it was not needed to apply any patch, even for kernels on version 5.10.
Tryied on Manjaro with 5.10.36-2-MANJARO kernel and It didn't work. Got any suggestions?
If anyone still wants to use it, I found a way to make it work.
1. First you need to use an old kernel version. I'm using arch linux so I installed the LTS version: `sudo pacman -S linux-lts` 2. Then you need to downgrade `bluez` also. I'm using version `5.56` which the source code can be downloaded [here](http://www.bluez.org/release-of-bluez-5-56/). To install it run these commands: * extract files * cd into directory * run `./configure` * run `make` * run `sudo make install` 1. Don't foget to set the modprode configuration: `sudo echo "options btusb reset=1 enable_autosuspend=0" >> /etc/modprobe.d/99-csr-bluetoothdongle.conf`After that, restart the system and pick the LTS kernel which is version
5.10.34-1-lts.
I tried before with newer kernels like version 5.11, 5.12 and I think they don't work at all. But it's still valid to try again, so if anyone could make it work on newer kernels, please tell me.
note: it was not needed to apply any patch, even for kernels on version 5.10.Tryied on Manjaro with 5.10.36-2-MANJARO kernel and It didn't work. Got any suggestions?
Manjaro uses to apply several patches on its kernel, so probably it won't work (I tried a lot to make it work on Manjaro before, even tried to build my own kernels and it has never worked).
So my suggestion is to move to Arch. Lately, I tried to boot with kernel 5.12 and the bluetooth does work. I don't know if it's because I have both 5.12 and 5.10 installed, but it's working on 5.12 too. I guess that new versions of bluez are the issue... so since it's working, I haven't updated bluez anymore.
Yesterday my Bluetooth stopped working again but it was different, I could find my devices but it was not connecting. I tried everything I could and in the end, I ended up installing the newest bluez packages via pacman, also replaced pulse-audio with pipewire, then removed the lts kernel and started using only the main kernel which is on version 5.12.6-arch1-1.
I can't say what made it work, but it's fully working now, so it's good to try to install these packages and test again:
bluez:
bluez 5.58-1
bluez-hid2hci 5.58-1
bluez-libs 5.58-1
bluez-utils 5.58-1
pipewire:
pipewire 1:0.3.28-1
pipewire-alsa 1:0.3.28-1
pipewire-jack 1:0.3.28-1
pipewire-media-session 1:0.3.28-1
pipewire-pulse 1:0.3.28-1
some packages from pulse that I still have installed (maybe are not necessary):
lib32-libpulse 14.2-2
libcanberra-pulse 0.30+2+gc0620e4-3
libpulse 14.2-3
pulseaudio-alsa 1:1.2.2-2
kernel:
linux 5.12.6.arch1-1
linux-api-headers 5.12.3-1
linux-headers 5.12.6.arch1-1
Another info is that until May 22nd, it was applying the patch on boot but it's not now. Probably it was the reason it stopped working, but after these updates, it seems to be working without the patch. This is the old log:
-- Boot c6f3c2981cc0429abaaf152410610b03 --
mai 22 13:24:27 rososto-arch kernel: Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds...
-- EDIT --
It seems that even with the newest bluez packages, I'm still running version 5.56. Probably it's because I've installed them manually via source code.
$ bluetoothctl --version
bluetoothctl: 5.56
Pretty insane turn of events. In any case someone is submitting HCI packets that lock it up. I wonder what's the bluez regression.
So are we still stuck at the regressive bluez behavior?
@NCatalani I'm ignoring bluez updates so I'm not following. But I'm still updating the kernel and it's working so far.
Thank you for the job but, unfortunately, it did not work on Ubuntu 20.04 on Kernel 5.10.12.
I tried all the solutions above but I could not get success.
I am using one of the most common chinese dongles with CSR 5.0, exactly the one in this link
In all the operations, when I restart the system and verify the status of dongle I get:hciconfig hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:12 ACL MTU: 679:8 SCO MTU: 48:16 DOWN RX bytes:367 acl:0 sco:0 events:12 errors:0 TX bytes:37 acl:0 sco:0 commands:12 errors:0Which indicates the dongle was recognized but is not operating. Furthermore, I tried to make it up manually by
sudo hciconfig hci0 upand again I could not activate the dongle getting the result:Can't init device hci0: Invalid argument (22)Monitoring the Bluetooth with
hcidumpcommand when I tried to make the dongle UP with the above command I got:> HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 status 0x00 HCI Version: 4.0 (0x6) HCI Revision: 0x3120 LMP Version: 4.0 (0x6) LMP Subversion: 0x22bb Manufacturer: Cambridge Silicon Radio (10) > HCI Event: Command Complete (0x0e) plen 4 Reset (0x03|0x0003) ncmd 1 status 0x00 > HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Features (0x04|0x0003) ncmd 1 status 0x00 Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 status 0x00 HCI Version: 4.0 (0x6) HCI Revision: 0x3120 LMP Version: 4.0 (0x6) LMP Subversion: 0x22bb Manufacturer: Cambridge Silicon Radio (10) > HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 1 status 0x00 bdaddr 00:1A:7D:DA:71:12 > HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 1 status 0x00 ACL MTU 679:8 SCO MTU 48:16 > HCI Event: Command Complete (0x0e) plen 7 Read Class of Device (0x03|0x0023) ncmd 1 status 0x00 class 0x000000 > HCI Event: Command Complete (0x0e) plen 252 Read Local Name (0x03|0x0014) ncmd 1 status 0x00 name 'CSR8510 A10.' > HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 1 status 0x00 voice setting 0x0000 > HCI Event: Command Complete (0x0e) plen 5 Read Number of Supported IAC (0x03|0x0038) ncmd 1 > HCI Event: Command Complete (0x0e) plen 8 Read Current IAC LAP (0x03|0x0039) ncmd 1 IAC 0x9e8b33 (General Inquiry Access Code) > HCI Event: Command Complete (0x0e) plen 4 Set Event Filter (0x03|0x0005) ncmd 1 status 0x12 Error: Invalid HCI Command ParametersFor this reason, I am asking for help since I am trying solutions to use the dongle on Linux for more than three weeks.
Since now, thank you for your help!
Hello my friend! After sniffing around the web, i found a solution for this issue.
I'm using Linux Lite 5.4 (Ubuntu 20.04 LTS Based) with Kernel 5.8.5. and my xing ling dongle is working perfectly.
I was receiving this same output in my hcidump.
I just made some changes in the btusb.c (drivers/bluetooth) and hci_core.c (net/bluetooth) files after manually extracted the kernel files before run the script (the kernel version i use is already patched, anyway):
In btusb.c i changed the line 32.
I replaced:
static bool enable_autosuspend = IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTOSUSPEND);
For:
static bool enable_autosuspend = 0;
In hci_core.c i just commented the lines 296 and 297.
Original:
295 /* Clear Event Filters */
296 flt_type = HCI_FLT_CLEAR_ALL;
297 hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
Commented:
295 /* Clear Event Filters */
296 //flt_type = HCI_FLT_CLEAR_ALL;
297 //hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
I ran the script after this changes, and Ta-Da! It's working perfectly!
[In Portuguese]
Caso o erro do seu hcidump seja igual ao do colega @Wanghley, que era exatamente o mesmo erro que o meu, ao rodar hcidump e em outra janela do terminal usar o hciconfig hcix (onde x é o id do dongle conectado, no meu caso aqui, hci0) down e depois up, recebendo essa mensagem acerca dos filtros de evento, basta antes de rodar o script .sh proceder às seguintes alterações nos arquivos btusb.c (drivers/bluetooth) e hci_core.c (net/bluetooth) dentro dos diretórios do kernel já extraído.
No meu caso, uso o Linux Lite 5.4, que é baseado no Ubuntu 20.04 LTS, com o Kernel 5.8.5 já modificado.
No arquivo btusb.c eu mudei a linha 32.
De:
static bool enable_autosuspend = IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTOSUSPEND);
Para:
static bool enable_autosuspend = 0;
No arquivo hci_core.c apenas é preciso comentar as linhas 296 e 297.
Original:
295 /* Clear Event Filters */
296 flt_type = HCI_FLT_CLEAR_ALL;
297 hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
Comentado:
295 /* Clear Event Filters */
296 //flt_type = HCI_FLT_CLEAR_ALL;
297 //hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
Após isso só fazer as alterações necessárias no script para rodar com a pasta do kernel já extraída, reiniciar o sistema e desfrutar do Bluetooth!
Hey, this is great. Super comprehensive. If no one beats me to it I might give this another go once I have time. We can probably mainline these quirks with a proper patch.
Alright, after a lot of debugging and regression testing this seems to do the job for me, no need for the sudo bash -C "echo 'options btusb reset=1 enable_autosuspend=0" >> /etc/modprobe.d/99-csr-bluetoothdongle.conf' file.
Turns out Hans de Goede (@jwrdegoede) has already done much of the work for us in this commit I have just noticed (thanks!) because I wasn't CC'd, we only need to make it more generic.
Please test the change below and let me know if it works for you too. We can submit a reworked patch officially and finally use our Bluetooth stuff without more fiddling.
diff -ur ../orig/linux-5.12.15/drivers/bluetooth/btusb.c ./drivers/bluetooth/btusb.c
--- ../orig/linux-5.12.15/drivers/bluetooth/btusb.c 2021-07-07 14:26:52.000000000 +0200
+++ ./drivers/bluetooth/btusb.c 2021-07-16 21:42:28.173087098 +0200
@@ -1901,10 +1901,7 @@
* To fix 2. clear the hci's can_wake flag, this way the hci
* will still be autosuspended when it is not open.
*/
- if (bcdDevice == 0x8891 &&
- le16_to_cpu(rp->lmp_subver) == 0x1012 &&
- le16_to_cpu(rp->hci_rev) == 0x0810 &&
- le16_to_cpu(rp->hci_ver) == BLUETOOTH_VER_4_0) {
+ if (1) {
bt_dev_warn(hdev, "CSR: detected a fake CSR dongle using a Barrot 8041a02 chip, this chip is very buggy and may have issues");
pm_runtime_allow(&data->udev->dev);
Here are some useful references:
- https://patchwork.kernel.org/project/bluetooth/patch/20210218123728.17067-2-hdegoede@redhat.com/
- https://patchwork.kernel.org/project/bluetooth/list/?submitter=582&state=%2A&archive=both
- https://patchwork.kernel.org/project/bluetooth/patch/20201205150201.5631-2-hdegoede@redhat.com/
- https://patchwork.kernel.org/project/bluetooth/patch/20201123101308.7291-3-hdegoede@redhat.com/
Just a quick heads up; I'm preparing a patch for submission. Massaging things a bit.
@Swyter good job in figuring out that more clones need the magic force-suspend-once workaround.
Note I did in fact Cc you on the original patch, see: https://lore.kernel.org/linux-bluetooth/20201205150201.5631-1-hdegoede@redhat.com/
And I also mentioned it in this bugzilla where you are active:
https://bugzilla.kernel.org/show_bug.cgi?id=60824#c163
Oh, boy. Thanks, I see, it probably got lost in the noise. I'm a mailing list newbie.
We'll see what other people think. I believe this is going to help a lot.
Ten years of broken dongles is more than enough. ¯\_(ツ)_/¯
There you go: https://patchwork.kernel.org/project/bluetooth/patch/906e95ce-b0e5-239e-f544-f34d8424c8da@gmail.com/
Should I open this gist with the new patch provided?
Feel free, the more testing the better. So far this super wonky dongle has been working so well after the patch that it's not even funny.
Well I could send you in my abomination that breaks with anything that isn't UHCI /s
I can't believe It finally works.
Dongle: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
System: Manjaro 21.0
Base Kernel: Linux 5.14.0-1-MANJARO
First I applied the btusb patch from @Swyter to the most recent kernel avaliable on the Manjaro repo (check philm's answer here https://archived.forum.manjaro.org/t/how-to-compile-the-mainline-kernel-the-manjaro-way/51700/10 for reference), but still It wasn't enough (stuck at the good ol' "Invalid HCI Command Parameters").
In order to circunvent this, I've also used a portion of @Samuckadf fix to patch hci_core too:
295 /* Clear Event Filters */
296 //flt_type = HCI_FLT_CLEAR_ALL;
297 //hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
And then It all worked flawlessly.
That's very encouraging. Thanks for trying it out, looks like we'll need to add another small quirk in a subsequent patch. It's also nice to confirm that applying the force-suspend workaround to every clone is either good or harmless, clearing up some contradictions. :)
This HCI_FLT_CLEAR_ALL patch should work on Linux 5.12.15:
diff -ur orig/./drivers/bluetooth/btusb.c ./drivers/bluetooth/btusb.c
--- orig/./drivers/bluetooth/btusb.c 2021-07-07 14:26:52.000000000 +0200
+++ ./drivers/bluetooth/btusb.c 2021-07-19 10:16:11.829201895 +0200
@@ -1879,6 +1879,7 @@
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
diff -ur orig/./include/net/bluetooth/hci.h ./include/net/bluetooth/hci.h
--- orig/./include/net/bluetooth/hci.h 2021-07-07 14:26:52.000000000 +0200
+++ ./include/net/bluetooth/hci.h 2021-07-19 11:21:11.611337353 +0200
@@ -246,6 +246,12 @@
* HCI after resume.
*/
HCI_QUIRK_NO_SUSPEND_NOTIFIER,
+
+ /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with
+ * HCI_FLT_CLEAR_ALL are ignored. A subset of the CSR controller
+ * clones struggle with this and instantly lock up.
+ */
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff -ur orig/./net/bluetooth/hci_core.c ./net/bluetooth/hci_core.c
--- orig/./net/bluetooth/hci_core.c 2021-07-07 14:26:52.000000000 +0200
+++ ./net/bluetooth/hci_core.c 2021-07-19 10:20:31.393235012 +0200
@@ -272,6 +272,7 @@
{
__le16 param;
__u8 flt_type;
+ struct hci_dev *hdev = req->hdev;
/* Read Buffer Size (ACL mtu, max pkt, etc.) */
hci_req_add(req, HCI_OP_READ_BUFFER_SIZE, 0, NULL);
@@ -291,9 +292,14 @@
/* Read Current IAC LAP */
hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL);
- /* Clear Event Filters */
- flt_type = HCI_FLT_CLEAR_ALL;
- hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ /* Clear Event Filters; some fake CSR controllers lock up after setting
+ * this type of filter, so avoid sending the request altogether.
+ */
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ {
+ flt_type = HCI_FLT_CLEAR_ALL;
+ hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ }
/* Connection accept timeout ~20 secs */
param = cpu_to_le16(0x7d00);
diff -ur orig/./net/bluetooth/hci_request.c ./net/bluetooth/hci_request.c
--- orig/./net/bluetooth/hci_request.c 2021-07-07 14:26:52.000000000 +0200
+++ ./net/bluetooth/hci_request.c 2021-07-19 10:11:19.531606972 +0200
@@ -1134,10 +1134,14 @@
static void hci_req_clear_event_filter(struct hci_request *req)
{
struct hci_cp_set_event_filter f;
+ struct hci_dev *hdev = req->hdev;
- memset(&f, 0, sizeof(f));
- f.flt_type = HCI_FLT_CLEAR_ALL;
- hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ {
+ memset(&f, 0, sizeof(f));
+ f.flt_type = HCI_FLT_CLEAR_ALL;
+ hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
+ }
/* Update page scan state (since we may have modified it when setting
* the event filter).
There has been some movement and changes in this area lately, so this won't apply on the current unstable version: torvalds/linux@e5b0ad6
Alright, if someone tries this cleaned up version for the latest development kernel please let me know how it goes. Better if you combine it with this patch.
From 4d5b0262d30dd6227d9bef96c2a2259bf1162350 Mon Sep 17 00:00:00 2001
From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Date: Mon, 19 Jul 2021 12:39:11 +0200
Subject: [PATCH] Bluetooth: Add a new quirk to skip HCI_FLT_CLEAR_ALL
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
---
drivers/bluetooth/btusb.c | 1 +
include/net/bluetooth/hci.h | 6 ++++++
net/bluetooth/hci_core.c | 12 +++++++++---
net/bluetooth/hci_request.c | 8 ++++++--
4 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 197cafe75..8fa07f9e3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1899,6 +1899,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index b80415011..a12178387 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -246,6 +246,12 @@ enum {
* HCI after resume.
*/
HCI_QUIRK_NO_SUSPEND_NOTIFIER,
+
+ /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with
+ * HCI_FLT_CLEAR_ALL are ignored. A subset of the CSR controller
+ * clones struggle with this and instantly lock up.
+ */
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 2560ed2f1..7ed355c3e 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -273,6 +273,7 @@ static void bredr_setup(struct hci_request *req)
{
__le16 param;
__u8 flt_type;
+ struct hci_dev *hdev = req->hdev;
/* Read Buffer Size (ACL mtu, max pkt, etc.) */
hci_req_add(req, HCI_OP_READ_BUFFER_SIZE, 0, NULL);
@@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req)
/* Read Current IAC LAP */
hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL);
- /* Clear Event Filters */
- flt_type = HCI_FLT_CLEAR_ALL;
- hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ /* Clear Event Filters; some fake CSR controllers lock up after setting
+ * this type of filter, so avoid sending the request altogether.
+ */
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ {
+ flt_type = HCI_FLT_CLEAR_ALL;
+ hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ }
/* Connection accept timeout ~20 secs */
param = cpu_to_le16(0x7d00);
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 1d14adc02..90a88539b 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance)
static void hci_req_clear_event_filter(struct hci_request *req)
{
struct hci_cp_set_event_filter f;
+ struct hci_dev *hdev = req->hdev;
+
+ if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
+ return;
- if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED))
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
return;
- if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
+ if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) {
memset(&f, 0, sizeof(f));
f.flt_type = HCI_FLT_CLEAR_ALL;
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
--
2.32.0
So far, things still work great with this. I don't see any regressions, but it needs to get some use before submission, as I can't test it directly.
Quick update; bringing good news: Marcel Holtmann has accepted the original force-suspend-for-everyone patch in bluetooth-next. So with this my main dongle should finally work great, finally.
I need you guys to test the HCI_FLT_CLEAR_ALL patch above and confirm that it works fine on your end when combined with the force-suspend one. Giving me a Tested-by: Name Surname <e-mail here>, if you'd like.
I have just tried the latest kernel 5.14 from Debian experimental, my understanding being that this patch is now included in the kernel, and that I don't have to patch/recompile a specific kernel.
Version:
5.14.0-trunk-arm64 #1 SMP Debian 5.14.3-1~exp1 (2021-09-12) aarch64
I have proper message making me think there is some try to suspend the device
dmesg | grep CSR
[ 36.534332] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 36.539116] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
My device is one of the generic 88.91:
_sudo lsusb -v -d 0a12:0001
Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 88.91
iManufacturer 0
iProduct 2 BT DONGLE10
iSerial 0
bNumConfigurations 1_
I can't manage to bring it up, I always end with the same error message (was already the case under default 5.10 bullseye kernel) :
sudo hciconfig hci0 up
Can't init device hci0: Invalid argument (22)
Did I miss one step?
TIA
No, you didn't miss anything; the current workarounds work on certain clones, and there are a lot of variants. Some like certain things and some don't, even with the new force-suspend hack. It did the trick for mine, at least. As you can see even when the quirk doesn't work it's still harmless.
Try out the HCI_FLT_CLEAR_ALL patch above, that one seems like it helps with another chunk of them. More patches like this one are needed to cover everything, quirk-wise. ¯\_(ツ)_/¯
My Bluetooth stopped working on the newest 5.14 kernel versions. I downgraded to the last 5.13 version and I got it working back again. Did it happen to anyone else?
@rosostolato Does reverting the force-suspend patch help? It can be that or regressions in the BlueZ part of the state machine.
What does your Read Local Version Information packet say when using hcidump/btmon? See in the Bugzilla thread for a how-to.
@rosostolato Does reverting the force-suspend patch help? It can be that or regressions in the BlueZ part of the state machine.
What does your Read Local Version Information packet say when using
hcidump? See in the Bugzilla thread for a how-to.
The first thing I tried was to downgrade bluez to version 5.56, but the error persisted. The problem was that it was not finding any bt controller. bluetoothctl list was saying "No default controller available". After that, I tried to revert the kernel to the first version of 5.14.x but it didn't work either. Then I finally reverted to 5.13.13. I didn't apply the force-suspend patch by myself and I don't know if it was implemented by the official kernel, but maybe the fix was a combination of both reverts (bluez + kernel).
I couldn't find the hcidump command but I can paste here my btmon (just the headers) output after it's working back again:
Bluetooth monitor ver 5.56
= Note: Linux version 5.13.13-arch1-1 (x86_64) 0.540997
= Note: Bluetooth subsystem version 2.22 0.540999
= New Index: 00:1A:7D:DA:71:10 (Primary,USB,hci0) [hci0] 0.540999
= Open Index: 00:1A:7D:DA:71:10 [hci0] 0.541000
= Index Info: 00:1A:7D:DA:71:10 (Cambridge Silicon Radio) [hci0] 0.541000
@ MGMT Open: bluetoothd (privileged) version 1.20 {0x0001} 0.541001
@rosostolato I see. Remove this part to get rid of the force-suspend stuff: https://github.com/torvalds/linux/blob/8274db0776d12de1be87a8504e60a608cb1b2212/drivers/bluetooth/btusb.c#L1937-L1951
Hi @Swyter, thanks for your efforts here. I really appreciate your work so far in trying to improve things.
I bought a cheap dongle and have been trying to get it working on my Raspberry Pi 2. Inspired by your efforts, I cross-compiled a more recent kernel (5.15) and applied your HCI_FLT_CLEAR_ALL patch from above.
The HCI_FLT_CLEAR_ALL patch is required to get my device to come up correctly (hciconfig hci0 up). Once applied, I think my device works; I can see other BT devices (e.g. my phone) when I run hcitool scan. (My main goal is to read the bluetooth advertisements sent out by a temperature monitor -- it works sporadically which makes me think it's a shoddy dongle rather than anything else).
Thanks for your work developing these patches :)
i'm an inexperienced user of linux and had problems following this thread. But i wonder which solution should try in Ubuntu 20.04.2 with kernel version 5.11.0-37-generic to solve this problem?
Also, in case that i should apply the patch, from were i can download the files referenced as the "above" ones?
Best regards.
Hi, @charluy. I would recommend first trying out a newer Linux kernel (from the current 5.15+ or just the latest 5.14 or 5.13 stable newer than 2021-09-10) which bundle the force-suspend patch. I know there are PPAs on Ubuntu to easily try newer versions out by installing some extra packages. If that still doesn't work you'd have to compile your own kernel version with the HCI_FLT_CLEAR_ALL patch above, which is just a text file that stores some code changes (the difference with the added and removed lines) against the official version. This is probably harder to do because requires you to use some terminal commands.
Hi, @ charluy. I would recommend first trying out a newer Linux kernel (from the current 5.15+ or just the latest 5.14 or 5.13 stable newer than 2021-09-10) which bundle the force-suspend patch. I know there are PPAs on Ubuntu to easily try newer versions out by installing some extra packages. If that still doesn't work you'd have to compile your own kernel version with the
HCI_FLT_CLEAR_ALLpatch above, which is just a text file that stores some code changes (the difference with the added and removed lines) against the official version. This is probably harder to do because requires you to use some terminal commands.
@Swyter I applied the mentioned patch on 5.14, still the dongle doesn't work. Even tried removing the force-suspend thing but to no gain.
I'm still getting Can't init device hci0: Invalid argument (22) for sudo hciconfig hci0 up. The device is detected but is unusable, having the same problem as @Wanghley here.
$ uname -a
Linux peesee 5.14.0-kali2-amd64 #1 SMP Debian 5.14.9-2kali1 (2021-10-04) x86_64 GNU/Linux
Used the following script to build the patched files.
This is just a slightly modified version of the script included in earlier revision of this gist.
#!/bin/bash
set -e
function info {
GREEN="\033[1;32m"
RESET="\033[0m"
echo -e "$GREEN==> $@$RESET"
}
modules=(
'drivers/bluetooth:btusb'
'net/bluetooth:bluetooth'
)
version="${1:-$(uname -r | cut -d'-' -f1)}"
extra="${2:-$(uname -r | cut -d'-' -f2-)}"
fullversion="$version-$extra"
name="linux-5.14.9"
info Setting up kernel config
make -C $name mrproper
cp /usr/lib/modules/$fullversion/build/.config $name/
cp /usr/lib/modules/$fullversion/build/Module.symvers $name/
make -C $name oldconfig
info Preparing kernel modules
make -C $name EXTRAVERSION=-$extra modules_prepare
for module in "${modules[@]}" ; do
module_path=${module%%:*}
module_name=${module#*:}
info Making $module_name kernel module
make -C $name M=$module_path
info Compressing $module_path/$module_name.ko kernel module
xz $name/$module_path/$module_name.ko
done
info Installing
sudo mkdir -p /usr/lib/modules/$fullversion/updates
for module in "${modules[@]}" ; do
module_path=${module%%:*}
module_name=${module#*:}
info Installing $module_name kernel module
sudo cp -f $name/$module_path/$module_name.ko.xz /usr/lib/modules/$fullversion/updates/$module_name.ko.xz
done
info Now you can reboot to load patched kernel modules
EDIT: dmesg shows this:
[ 167.286384] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[ 167.682410] usb 1-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 167.682421] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 167.682426] usb 1-1: Product: BT DONGLE10
[ 167.818506] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[ 168.036517] Bluetooth: Core ver 2.22
[ 168.036586] NET: Registered PF_BLUETOOTH protocol family
[ 168.036588] Bluetooth: HCI device and connection manager initialized
[ 168.037723] Bluetooth: HCI socket layer initialized
[ 168.037734] Bluetooth: L2CAP socket layer initialized
[ 168.037745] Bluetooth: SCO socket layer initialized
[ 168.083062] usbcore: registered new interface driver btusb
[ 168.108477] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 168.108490] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 168.374069] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 168.374078] Bluetooth: BNEP filters: protocol multicast
[ 168.374086] Bluetooth: BNEP socket layer initialized
After sudo hcionfig hci0 up, I get
[ 788.175519] debugfs: File 'dut_mode' in directory 'hci0' already present!
First of all, this gist thread is amazing!
@Swyter,
Did the same as @siddhpant but for kernel 5.15, Ubuntu 20.04.3 LTS. Still not working =/
$ uname -a
Linux ubuntu-pc 5.15.0-051500-generic #202110312130 SMP Sun Oct 31 21:33:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ lsusb
...
Bus 001 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
...
$ sudo dmesg
[ 295.508039] usb 1-3: new full-speed USB device number 6 using xhci_hcd
[ 295.833838] usb 1-3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 295.833845] usb 1-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 295.833849] usb 1-3: Product: BT DONGLE10
[ 295.851600] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 295.851614] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
I'm close to giving up and buying an rtl8761b compatible.
I actually bought one of those fake and mega cheap V5.0-marked Chinese dongles for debugging; the no-spaces version.
Fiddled around with it and it didn't work on bleeding-edge Linux, as expected. Same dmesg output as shown above.
The fun thing is that (apart from, you know, neither being Bluetooth 4+ or a real CSR) it didn't even work on Windows out of the box without installing some funky Bluetooth vendor stack and driver which you can download from here: https://www.gembird.com/item.aspx?id=9013
Here's a backup of the installer, just for completeness: https://web.archive.org/web/20210201002621/https://www.gembird.com/Repository/9013/BTD-MINI4_driver_266C242F-388A-4CA8-A935-DBF5C724B0BE.rar (another version; here)
I did some USB controller captures on Windows with usbpcap so see what's up and it seems to like using a lot of vendor commands.
I may give it another go once I have more free time. But feel free to contribute and improve the existing workarounds. ¯\_(ツ)_/¯
Just another update, I just tried your patch with kernel 5.14.16-051416-generic and it yield the same result.
Looking at the btmon, it has a suspicious message regarding the event filter:
> HCI Event: Command Complete (0x0e) plen 4 #24 [hci0] 13.810297
Set Event Filter (0x03|0x0005) ncmd 1
Status: Invalid HCI Command Parameters (0x12)
= Close Index: 00:1A:7D:DA:71:12
complete btmon output
sudo btmon
Bluetooth monitor ver 5.53
= Note: Linux version 5.14.16-051416-generic (x86_64) 0.253873
= Note: Bluetooth subsystem version 2.22 0.253878
@ MGMT Open: btmon (privileged) version 1.21 {0x0001} 0.253899
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0) [hci0] 13.741688
= Open Index: 00:00:00:00:00:00 [hci0] 13.742039
< HCI Command: Read Local Version I.. (0x04|0x0001) plen 0 #1 [hci0] 13.742252
> HCI Event: Command Complete (0x0e) plen 12 #2 [hci0] 13.745288
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.0 (0x06) - Revision 12576 (0x3120)
LMP version: Bluetooth 4.0 (0x06) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Reset (0x03|0x0003) plen 0 #3 [hci0] 13.745352
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 13.757444
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported.. (0x04|0x0003) plen 0 #5 [hci0] 13.757481
> HCI Event: Command Complete (0x0e) plen 12 #6 [hci0] 13.760294
Read Local Supported Features (0x04|0x0003) ncmd 1
Status: Success (0x00)
Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7
3 slot packets
5 slot packets
Encryption
Slot offset
Timing accuracy
Role switch
Sniff mode
Power control requests
Channel quality driven data rate (CQDDR)
SCO link
HV2 packets
HV3 packets
CVSD synchronous data
Power control
Transparent synchronous data
Flow control lag (most significant bit)
Enhanced Data Rate ACL 2 Mbps mode
Enhanced inquiry scan
Interlaced inquiry scan
Interlaced page scan
RSSI with inquiry results
Extended SCO link (EV3 packets)
EV4 packets
EV5 packets
AFH capable slave
AFH classification slave
LE Supported (Controller)
3-slot Enhanced Data Rate ACL packets
5-slot Enhanced Data Rate ACL packets
Pause encryption
AFH capable master
AFH classification master
Enhanced Data Rate eSCO 2 Mbps mode
Extended Inquiry Response
Simultaneous LE and BR/EDR (Controller)
Secure Simple Pairing
Encapsulated PDU
Erroneous Data Reporting
Non-flushable Packet Boundary Flag
Link Supervision Timeout Changed Event
Inquiry TX Power Level
Enhanced Power Control
Extended features
Unknown features (0x4000000000000000)
< HCI Command: Read Local Version I.. (0x04|0x0001) plen 0 #7 [hci0] 13.760335
> HCI Event: Command Complete (0x0e) plen 12 #8 [hci0] 13.764309
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.0 (0x06) - Revision 12576 (0x3120)
LMP version: Bluetooth 4.0 (0x06) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0 #9 [hci0] 13.764346
> HCI Event: Command Complete (0x0e) plen 10 #10 [hci0] 13.768297
Read BD ADDR (0x04|0x0009) ncmd 1
Status: Success (0x00)
Address: 00:1A:7D:DA:71:12 (cyber-blue(HK)Ltd)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0 #11 [hci0] 13.768374
= bluetoothd: Bluetooth daemon 5.53 13.772046
> HCI Event: Command Complete (0x0e) plen 11 #12 [hci0] 13.772286
Read Buffer Size (0x04|0x0005) ncmd 1
Status: Success (0x00)
ACL MTU: 679 ACL max packet: 8
SCO MTU: 48 SCO max packet: 16
< HCI Command: Read Class of Device (0x03|0x0023) plen 0 #13 [hci0] 13.772316
@ MGMT Open: bluetoothd (privileged) version 1.21 {0x0002} 13.774295
= bluetoothd: Starting SDP server 13.774430
> HCI Event: Command Complete (0x0e) plen 7 #14 [hci0] 13.776297
Read Class of Device (0x03|0x0023) ncmd 1
Status: Success (0x00)
Class: 0x000000
Major class: Miscellaneous
Minor class: 0x00
< HCI Command: Read Local Name (0x03|0x0014) plen 0 #15 [hci0] 13.776329
> HCI Event: Command Complete (0x0e) plen 252 #16 [hci0] 13.795470
Read Local Name (0x03|0x0014) ncmd 1
Status: Success (0x00)
Name: CSR8510 A10
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0 #17 [hci0] 13.795506
> HCI Event: Command Complete (0x0e) plen 6 #18 [hci0] 13.798288
Read Voice Setting (0x03|0x0025) ncmd 1
Status: Success (0x00)
Setting: 0x0000
Input Coding: Linear
Input Data Format: 1's complement
Input Sample Size: 8-bit
# of bits padding at MSB: 0
Air Coding Format: CVSD
< HCI Command: Read Number of Supp.. (0x03|0x0038) plen 0 #19 [hci0] 13.798315
> HCI Event: Command Complete (0x0e) plen 5 #20 [hci0] 13.802289
Read Number of Supported IAC (0x03|0x0038) ncmd 1
Status: Success (0x00)
Number of IAC: 2
< HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 #21 [hci0] 13.802324
> HCI Event: Command Complete (0x0e) plen 8 #22 [hci0] 13.806301
Read Current IAC LAP (0x03|0x0039) ncmd 1
Status: Success (0x00)
Number of IAC: 1
Access code: 0x9e8b33 (General Inquiry)
< HCI Command: Set Event Filter (0x03|0x0005) plen 1 #23 [hci0] 13.806335
Type: Clear All Filters (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #24 [hci0] 13.810297
Set Event Filter (0x03|0x0005) ncmd 1
Status: Invalid HCI Command Parameters (0x12)
= Close Index: 00:1A:7D:DA:71:12 [hci0] 13.810343
@ MGMT Command: Read Management Version I.. (0x0001) plen 0 {0x0002} 13.815191
@ MGMT Event: Command Complete (0x0001) plen 6 {0x0002} 13.815208
Read Management Version Information (0x0001) plen 3
Status: Success (0x00)
Version: 1.21
= bluetoothd: Bluetooth management interface 1.21 initialized 13.815280
@ MGMT Command: Read Management Supported.. (0x0002) plen 0 {0x0002} 13.815290
@ MGMT Event: Command Complete (0x0001) plen 259 {0x0002} 13.815296
Read Management Supported Commands (0x0002) plen 256
Status: Success (0x00)
Commands: 84
Read Controller Index List (0x0003)
Read Controller Information (0x0004)
Set Powered (0x0005)
Set Discoverable (0x0006)
Set Connectable (0x0007)
Set Fast Connectable (0x0008)
Set Bondable (0x0009)
Set Link Security (0x000a)
Set Secure Simple Pairing (0x000b)
Set High Speed (0x000c)
Set Low Energy (0x000d)
Set Device Class (0x000e)
Set Local Name (0x000f)
Add UUID (0x0010)
Remove UUID (0x0011)
Load Link Keys (0x0012)
Load Long Term Keys (0x0013)
Disconnect (0x0014)
Get Connections (0x0015)
PIN Code Reply (0x0016)
PIN Code Negative Reply (0x0017)
Set IO Capability (0x0018)
Pair Device (0x0019)
Cancel Pair Device (0x001a)
Unpair Device (0x001b)
User Confirmation Reply (0x001c)
User Confirmation Negative Reply (0x001d)
User Passkey Reply (0x001e)
User Passkey Negative Reply (0x001f)
Read Local Out Of Band Data (0x0020)
Add Remote Out Of Band Data (0x0021)
Remove Remote Out Of Band Data (0x0022)
Start Discovery (0x0023)
Stop Discovery (0x0024)
Confirm Name (0x0025)
Block Device (0x0026)
Unblock Device (0x0027)
Set Device ID (0x0028)
Set Advertising (0x0029)
Set BR/EDR (0x002a)
Set Static Address (0x002b)
Set Scan Parameters (0x002c)
Set Secure Connections (0x002d)
Set Debug Keys (0x002e)
Set Privacy (0x002f)
Load Identity Resolving Keys (0x0030)
Get Connection Information (0x0031)
Get Clock Information (0x0032)
Add Device (0x0033)
Remove Device (0x0034)
Load Connection Parameters (0x0035)
Read Unconfigured Controller Index List (0x0036)
Read Controller Configuration Information (0x0037)
Set External Configuration (0x0038)
Set Public Address (0x0039)
Start Service Discovery (0x003a)
Read Local Out Of Band Extended Data (0x003b)
Read Extended Controller Index List (0x003c)
Read Advertising Features (0x003d)
Add Advertising (0x003e)
Remove Advertising (0x003f)
Get Advertising Size Information (0x0040)
Start Limited Discovery (0x0041)
Read Extended Controller Information (0x0042)
Set Appearance (0x0043)
Get PHY Configuration (0x0044)
Set PHY Configuration (0x0045)
Reserved (0x0046)
Reserved (0x0047)
Reserved (0x0048)
Reserved (0x0049)
Reserved (0x004a)
Reserved (0x004b)
Reserved (0x004c)
Reserved (0x004d)
Reserved (0x004e)
Reserved (0x004f)
Reserved (0x0050)
Reserved (0x0051)
Reserved (0x0052)
Reserved (0x0053)
Reserved (0x0054)
Reserved (0x0055)
Reserved (0x0056)
Events: 42
Controller Error (0x0003)
Index Added (0x0004)
Index Removed (0x0005)
New Settings (0x0006)
Class Of Device Changed (0x0007)
Local Name Changed (0x0008)
New Link Key (0x0009)
New Long Term Key (0x000a)
Device Connected (0x000b)
Device Disconnected (0x000c)
Connect Failed (0x000d)
PIN Code Request (0x000e)
User Confirmation Request (0x000f)
User Passkey Request (0x0010)
Authentication Failed (0x0011)
Device Found (0x0012)
Discovering (0x0013)
Device Blocked (0x0014)
Device Unblocked (0x0015)
Device Unpaired (0x0016)
Passkey Notify (0x0017)
New Identity Resolving Key (0x0018)
New Signature Resolving Key (0x0019)
Device Added (0x001a)
Device Removed (0x001b)
New Connection Parameter (0x001c)
Unconfigured Index Added (0x001d)
Unconfigured Index Removed (0x001e)
New Configuration Options (0x001f)
Extended Index Added (0x0020)
Extended Index Removed (0x0021)
Local Out Of Band Extended Data Updated (0x0022)
Advertising Added (0x0023)
Advertising Removed (0x0024)
Extended Controller Information Changed (0x0025)
PHY Configuration Changed (0x0026)
Reserved (0x0027)
Reserved (0x002a)
Reserved (0x002b)
Reserved (0x002c)
Reserved (0x002d)
Reserved (0x002e)
@ MGMT Command: Read Controller Index List (0x0003) plen 0 {0x0002} 13.815319
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0002} 13.815323
Read Controller Index List (0x0003) plen 2
Status: Success (0x00)
Controllers: 0
@raphaelbs Thanks for the log. Check out this patch, or the one above, and see if that does the trick: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3818325
@Swyter this was the patch that I tried. Maybe it is not being applied correctly? (I'm a noob at this)
I'm running the create_btusb_patch.sh but I replaced the fix_csr_dongle.patch with your patch.
my version of the `create_btusb_patch.sh`
#!/usr/bin/env sh
set -e
function info {
GREEN="\033[1;32m"
RESET="\033[0m"
echo -e "$GREEN==> $@$RESET"
}
version="${1:-$(uname -r | cut -d'-' -f1)}"
# version="5.15"
extra="${2:-$(uname -r | cut -d'-' -f2-)}"
fullversion="$version-$extra"
modules=(
'drivers/bluetooth:btusb'
'net/bluetooth:bluetooth'
)
info Making patch for kernel $fullversion
name="linux-$version"
archive="$name.tar.xz"
info Downloading kernel $name
wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/$archive -O $archive
info Extracting $archive
tar -xJf $archive
info Setting up kernel config
make -C $name mrproper
cp /usr/lib/modules/$fullversion/build/.config $name/
cp /usr/lib/modules/$fullversion/build/Module.symvers $name/
make -C $name oldconfig
info Applying CSR dongle fix
patch -p1 -d $name < fix_csr_dongle.patch
info Preparing kernel modules
make -C $name EXTRAVERSION=-$extra modules_prepare
for module in "${modules[@]}" ; do
module_path=${module%%:*}
module_name=${module#*:}
info Making $module_name kernel module
make -C $name M=$module_path
info Compressing $module_path/$module_name.ko kernel module
xz $name/$module_path/$module_name.ko
done
info Installing
sudo mkdir -p /usr/lib/modules/$fullversion/updates
for module in "${modules[@]}" ; do
module_path=${module%%:*}
module_name=${module#*:}
info Installing $module_name kernel module
sudo cp -f $name/$module_path/$module_name.ko.xz /usr/lib/modules/$fullversion/updates/$module_name.ko.xz
done
# info Copying csr-bluetoothdongle.conf to /etc/modprobe.d/ with contents:
# cat csr-bluetoothdongle.conf
# sudo cp -f csr-bluetoothdongle.conf /etc/modprobe.d/99-csr-bluetoothdongle.conf
info Running 'initramfs'
sudo update-initramfs -u
info Removing temp files
rm -f $archive
rm -rf $name
info Now you can reboot to load patched kernel modules
Great. Then my patch is probably missing some other occurrences where that command is being sent, or they have changed the code. There are other patches in the Bugzilla thread for this issue that essentially unconditionally disable the whole clear-all filtering thing at the driver level. They are one-liners and they should apply easily.
I didn't notice because what all these patches do is tell Linux to never send that command to keep the dongle happy, and in your log it still happens. And the controller locks up after responding to it.
What is the recommended approach to applying those patches? I'm reading about live patching but I'm way over my head here
This fix, you can probably open that file directly in a text editor and comment (prepend with // to disable them) the lines out:
Then recompile the module, copy it and reload, or restart like before.
Note: Search for HCI_FLT_CLEAR_ALL, the offending command should be next to it. There may be multiple copies of it in various files.
Following your suggestion, I commented out:
(sorry for the poor man's diff. I don't have the git repo for the kernel version atm)
// linux-5.14.16/net/bluetooth/hci_core.c
/* Clear Event Filters; some fake CSR controllers lock up after setting
* this type of filter, so avoid sending the request altogether.
*/
// if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
// {
// flt_type = HCI_FLT_CLEAR_ALL;
// hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
// }// linux-5.14.16/net/bluetooth/hci_event.c
// if (cp->flt_type == HCI_FLT_CLEAR_ALL)
// hci_dev_clear_flag(hdev, HCI_EVENT_FILTER_CONFIGURED);
// else
// hci_dev_set_flag(hdev, HCI_EVENT_FILTER_CONFIGURED);and
// linux-5.14.16/net/bluetooth/hci_request.c
// if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
// memset(&f, 0, sizeof(f));
// f.flt_type = HCI_FLT_CLEAR_ALL;
// hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
// }And this is already on top of the other patches.
Unfortunately, btmon shows the same log. Feels like the changes aren't being applied at all. I'm rebooting after each change.
The script's output after recompiling with the changes above, twice:
$ sudo bash create_btusb_patch.sh
==> Making patch for kernel 5.14.16-051416-generic
==> Preparing kernel modules
make: Entering directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtool
DESCEND bpf/resolve_btfids
make: Leaving directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
==> Making btusb kernel module
make: Entering directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
LD [M] drivers/bluetooth/btusb.ko
make: Leaving directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
==> Compressing drivers/bluetooth/btusb.ko kernel module
==> Making bluetooth kernel module
make: Entering directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
LD [M] net/bluetooth/bluetooth.ko
make: Leaving directory '/home/raphael-brandao/Desktop/bt-patch/linux-5.14.16'
==> Compressing net/bluetooth/bluetooth.ko kernel module
==> Installing
==> Installing btusb kernel module
==> Installing bluetooth kernel module
==> Running initramfs
update-initramfs: Generating /boot/initrd.img-5.14.16-051416-generic
==> Now you can reboot to load patched kernel modules
My bt dongle needs the patch Bluetooth: Add a new quirk to skip "HCI_FLT_CLEAR_ALL" proposed by @Swyter
I am testing on 5.15.6 which already contains all the suspend patches; the patch exactly as in the comment applies cleanly and works. I've submitted a PR to the kernel package on void linux with this patch added (void-linux/void-packages#34359) and I'm using this kernel on my main desktop. I hope this can be merged in the mainline kernel.
Some info about my dongle:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
bcdDevice 88.91
...
Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7
Name: 'CSR8510 A10.'
HCI Version: 4.0 (0x6) Revision: 0x3120
LMP Version: 4.0 (0x6) Subversion: 0x22bb
On dmesg the product name is BT DONGLE10.
As for the suspend workaround: I do get " hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"; removing that workaround doesn't affect my device, but it doesn't seem to do any harm afaict (other than having an error in dmesg, maybe this can be replaced by a warning instead)
Feel free to add Tested-by: Gonzalo Tornaría <tornaria@cmat.edu.uy> if that helps in any way to get this merged.
@tornaria It does help, a lot. I was waiting for more feedback before submitting.
Yeah, the generic force-suspend patch should be harmless, but because there's a whole zoo of fakes we need to cast a wide net to make them all happy without too much whitelisting. You are right, better show a warning. I'll try to get my other patch into mainline once I have a bit more time.
Thanks a lot for the thorough testing and comment. I'll take your Tested-by. If anyone else wants to give it another test run and show up in the eventual patch submission let me know. :)
Thanks! Let me know if I can help with more testing or give more information about this dongle. I'll be using this kernel with this bt dongle in my main desktop from now on, so I'll report back if I have any trouble. I'm using a BT keyboard to write this 👏
If it helps anyone, the raw patch (verbatim copy of the comment above) is here: https://raw.githubusercontent.com/void-linux/void-packages/be587c070716d820eceee2377f966874ae51eb67/srcpkgs/linux5.15/patches/btusb-quirk-HCI_FLT_CLEAR_ALL.patch
Hey 👋
I just found this GitHub gist thread, and it says it is not working on kernel 5.11 and above, do you guys know if there is a workaround? I can see that you are discussing a workaround above, but I am not quite sure how to approach it.
I am on Archlinux kernel 5.15.7, and you can see my output of lsusb below:
As of right now, I can not get the dongle to work on my Arch Linux Gnome desktop.
Thanks in advance for the help!
Hi, @ViggoGaming. The lsusb output isn't useful here, every Chinese dongle seems to use this VID:PID combination, in fact they are all so alike that we had to concoct a really tricky detection function that splits the codepaths into legit and fake.
Personally, I'm more interested in photos of the exterior and the chip/PCB, as well as their Read Local Version Information packet, or equivalent HCI Version / Revision and LMP Version / Subversion. See above or in the Bugzilla thread about how to do it. There are various ways.
I'd learn to recompile your own kernel and modules, older versions of this Gist had some useful instructions, another common way is to loosely follow that ubiquitous Anne Pro CSR reddit thread:
https://old.reddit.com/r/AnnePro/comments/e76ij8/csr_40_bluetooth_dongle_on_linux/
Keep in mind that you'd have to use the patch we were talking about in the previous comments, the others are already included officially/merged/mainlined. Good luck.
Many thanks for the answer @Swyter
Do you know if the patch discussed above will be packaged into the newer kernels?
Yeah, I think we were talking about this in the thread last time; I'll try to get the patches in shape and ask them to review them by e-mail a few times until they get good enough for the official thing, and some subsystem maintainer likes it enough to merge it.
After that you need to wait for the bundle of patches of that subsystem to get merged by Linus Torvalds at the top, he then tags/stamps a new version every X weeks and after three or four months it should arrive on Arch and other rolling-ish/early bird distros.
It can take years for more stable distros to get it if you don't ask them to include your patch in the stable "backports".
So yeah, not the most straightforward thing. But that is how all this works. It's free, but takes some time and patience for the back-and-forth.
@Swyter Okay thanks sound good! I can just apply the patch my self though?
After a couple days banging my head around this, I finally was able to get my CSR "5.0" dongle to work. Thank you all so much for this thread. What worked for me was basically using the script above to automate kernel module compilation, but I modified it to apply the HCI_FLT_CLEAR_ALL patch instead of the old patch. I was using a newer version of the kernel anyways (5.15.7), so the force-suspend patch was already in as well.
I also had to change some flags in the .config file to disable module signing and to tinker with version magic before compilation.
Don't know if it helps but here's info about my device with lsusb:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 88.91
iManufacturer 0
iProduct 2 BT DONGLE10
iSerial 0
bNumConfigurations 1
I'm using 5.15.7-1-MANJARO x86_64, though I also tested it with kernel 5.14.21-2 and it worked.
To anyone who wants to try and is a Linux beginner like me, I strongly encourage you to modprobe the module after you finish installing and check the outputs with dmesg | grep btusb or something. This is how I figured out what was missing after several attempts.
That's great to read, @lemonteus. If you don't mind your name and e-mail being public it would be neat if you could give me permission to include you in the Tested-by: Name <em@il.com> lines for the final submission. The more real-life testers the better; I don't want to cause regressions.
Who knows how many variants are out there. I actually bought another buggy dongle just to fix it.
Oh sure @Swyter, meant to do so before but forgot.
Tested by: Mateus Lemos <lemonsmateus@gmail.com>
Hi guys, is there any kernel ready to use/already patched to download?
I'd rather change my distro and reinstall it than do this whole process.
I'm on Debian testing now.
Hello
I am using a ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) device on an old machine with kernel 3.
The device works initially (I am periodically using a hcitool name to verify that another device is close) but after a few hours it stops working (the other device is there but no response is returned).
At that point dmesg says: Bluetooth: hci0 command tx timeout for every time the hcitool command runs
After unplugging and re-plugging the dongle, it starts working again
I tried to set options btusb reset=1 enable_autosuspend=0 in /etc/modprobe.d/csr-bluetoothdongle.conf but I get error btusb: Unknown parameter 'enable_autosuspend' (guessing because of the old kernel)
Any ideas about this ?
edit: I should also mention that with an other dongle (a lot older BT v1) things work fine non-stop, but I just need newer BT version so that is why I am tryin to make this v5 BT device work
Just a quick heads-up, I have submitted the initial version of the HCI_FLT_CLEAR_ALL patch (the one that fixes the fake "V5.0" CSR dongles) for review, but this may take a while:
https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/
@Swyter just tested your patch on top of 5.16-rc8, but it still fails for me:
[ 1225.690537] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 1230.924877] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 1236.043828] Bluetooth: hci0: setting interface failed (110)
My device has a different bcdDevice, but it's still recognized as a 'fake' one:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 25.20
iManufacturer 0
iProduct 2 CSR8510 A10
iSerial 0
bNumConfigurations 1
I loaded the btusb module using reset=1 and enable_autosuspend=0. I have a spare machine for compiling and testing some paches, please let me know if I can test any new version of your patchset, or if I can provide more info about my device.
@Swyter if I comment the PM code in btusb_setup_csr, along with your patch, can setup the interface correctly, but return other errors:
[ 3796.392461] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 3796.464490] Bluetooth: RFCOMM TTY layer initialized
[ 3796.464495] Bluetooth: RFCOMM socket layer initialized
[ 3796.464498] Bluetooth: RFCOMM ver 1.11
[ 3803.657404] Bluetooth: hci0: failed to disable LE scan: status 0x1f
[ 3803.657403] Bluetooth: hci0: command 0x200c tx timeout
[ 3808.777299] Bluetooth: hci0: command 0x200c tx timeout
I don't understand a thing about bluetooth, but I'll do some research and try to fix it for my device if time allows. In the meantime, do you have any idea what can be wrong in this case? Thanks!
@marcosps I see. The most important thing to distinguish your dongle from the rest is getting the Read Local Version Information packet with hcidump/btmon, we're making a list, trying to classify them by needs and common traits. Also, try running it without kernel arguments.
Knowing how your dongle looks like (PCB/exterior/chip markings) and where you bought it helps, too.
Another thing, if you comment out the pm code without applying the HCI_FLT_CLEAR_ALL patch, does your controller get stuck, too? You can use sudo btmon to see what happens.
I want to see if it has also that (HCI_OP_SET_EVENT_FLT) problem with other issues on top or it's broken in a completely different way. So the logs help.
Hi,
I would like to thank and congratulate everyone involved in this gist, you are clearly putting a lot of effort into making this BT dongle work.
On Arch Linux 5.16.1-arch1-1 my ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) worked after @bennehcarvalho's simple solution
[19:00:43] ik@lostark ~ $ sudo btmon
Bluetooth monitor ver 5.63
= Note: Linux version 5.16.1-arch1-1 (x86_64) 0.438059
= Note: Bluetooth subsystem version 2.22 0.438062
@ MGMT Open: bluetoothd (privileged) version 1.21 {0x0001} 0.438064
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0) [hci0] 3.079067
= Open Index: 00:00:00:00:00:00 [hci0] 3.079086
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 3.079091
> HCI Event: Command Status (0x0f) plen 4 #2 [hci0] 3.079385
NOP (0x00|0x0000) ncmd 1
Status: Success (0x00)
> HCI Event: Hardware Error (0x10) plen 1 #3 [hci0] 3.080379
Code: 0x35
> HCI Event: Command Complete (0x0e) plen 12 #4 [hci0] 3.081386
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.0 (0x06) - Revision 8891 (0x22bb)
LMP version: Bluetooth 4.0 (0x06) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Reset (0x03|0x0003) plen 0
@Swyter here is the btmon output related to Local Version Info:
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 6.270237
> HCI Event: Command Complete (0x0e) plen 12 #2 [hci0] 6.272023
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 12576 (0x3120)
LMP version: Bluetooth 5.0 (0x09) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
You were right, removing the PM code make it to not get stuck, but it has some other failing cases as I posted before:
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #96 [hci0] 7.817033
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817100
Start Service Discovery (0x003a) plen 1
Status: Success (0x00)
Address type: 0x07
BR/EDR
LE Public
LE Random
@ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 7.817107
Address type: 0x07
BR/EDR
LE Public
LE Random
Discovery: Enabled (0x01)
@ MGMT Command: Start Service Discovery (0x003a) plen 4 {0x0001} [hci0] 7.817231
Address type: 0x07
BR/EDR
LE Public
LE Random
RSSI: invalid (0x7f)
UUIDs: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817237
Start Service Discovery (0x003a) plen 1
Status: Busy (0x0a)
Address type: 0x07
BR/EDR
LE Public
LE Random
@ MGMT Command: Start Service Discovery (0x003a) plen 4 {0x0001} [hci0] 7.817312
Address type: 0x07
BR/EDR
LE Public
LE Random
RSSI: invalid (0x7f)
UUIDs: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817315
Start Service Discovery (0x003a) plen 1
Status: Busy (0x0a)
Address type: 0x07
BR/EDR
LE Public
LE Random
Here it fails twice (retry maybe?). Here is states where it stops working:
HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #97 [hci0] 13.180894
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29 #98 [hci0] 15.488224
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: 76:CA:6D:37:3E:20 (Resolvable)
Data length: 17
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 12 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 151c1ee9c9
RSSI: 0 dBm (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 #99 [hci0] 15.490216
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Random (0x01)
Address: 76:CA:6D:37:3E:20 (Resolvable)
Data length: 0
RSSI: 0 dBm (0x00)
@ MGMT Event: Device Found (0x0012) plen 31 {0x0001} [hci0] 15.490302
LE Address: 76:CA:6D:37:3E:20 (Resolvable)
RSSI: 0 dBm (0x00)
Flags: 0x00000000
Data length: 17
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 12 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 151c1ee9c9
@ MGMT Command: Stop Discovery (0x0024) plen 1 {0x0001} [hci0] 17.604224
Address type: 0x07
BR/EDR
LE Public
LE Random
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #100 [hci0] 17.604369
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 19.612835
Stop Discovery (0x0024) plen 1
Status: Failed (0x03)
Address type: 0x07
BR/EDR
LE Public
LE Random
Now I'll try to digest this and map the output to the code :)
Again, this working without your patch, only by commenting the autosuspend and pm_* functions in btusb_setup_csr.
Ola @igorkelvin :)
I tried the same steps (reset=1 and autosuspend disabled, but in my case it didn't work). Thanks for sharing!
@Swyter maybe we could set the reset and autosuspend for some specific devices, like the one from @igorkelvin , similar to what we have for i8042 devices for disabling selftests.
$ sudo hciconfig hci0 up
Can't init device hci0: Invalid argument (22)
[ 921.000192] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 921.000198] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 921.021185] debugfs: File 'dut_mode' in directory 'hci0' already present!
When I try to bring up hci0 on one of those "5.0" dongles. It actually identifies as:
[ 811.722229] usb 1-1: Product: BT DONGLE10
@sfjuocekr With any luck, this is what my patch attempts to solve via quirk, I just sent the v2 for review, give it a go: https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/
Yea, I found it already and will test it probably tomorrow! Had something else to work on :)
ok im running 5.16-5 and idk how to patch kernel this way, i use pamac manager and install dkm, can yall make a AUR for Arch users cauce i bought 10 of these bluetooth and none work on Linux
Quick heads up, had some time today and sent v3 for kernel review. We'll see if they like it:
https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
Quick heads up, had some time today and sent
v3for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
Do you think that I should unarchive this gist with the new patch? That is the minimal kernel version to apply without issues?
This patch only works on very recent kernels (they changed how pretty much the Bluetooth protocol implementation works in January), I had to rewrite it. But there are some older versions here, up in the comments. If they merge this one all my Chinese dongles will run alright.
Super neat, the v4 patch series has been merged by Marcel in bluetooth-next, maybe it even gets backported to stable kernels:
- https://git.kernel.org/bluetooth/bluetooth-next/c/d35c9b22957a
- https://git.kernel.org/bluetooth/bluetooth-next/c/4afc6c743557
That means it's probably going to get merged into the parent net-next tree and if there are no weird regressions Linus Torvalds merges that and it's going to eventually be part of the next kernel version. Whenever that happens, thanks for testing. @tornaria and @lemonteus are credited in the commit log. :)
With this all my Chinese dongles (even those purchased for kernel work) finally work on Linux. I'm sure there are still more quirks to add, but hopefully other random people will start chipping away at it as a learning experience. It's been fun.
YOU ROCK MAN THANKS FOR YOUR WORK!
Super neat, the
v4patch series has been merged by Marcel inbluetooth-next, maybe it even gets backported to stable kernels:* https://git.kernel.org/bluetooth/bluetooth-next/c/d35c9b22957a * https://git.kernel.org/bluetooth/bluetooth-next/c/4afc6c743557That means it's probably going to get merged into the parent
net-nexttree and if there are no weird regressions Linus Torvalds merges that and it's going to eventually be part of the next kernel version. Whenever that happens, thanks for testing. @tornaria and @lemonteus are credited in the commit log. :)With this all my Chinese dongles (even those purchased for kernel work) finally work on Linux. I'm sure there are still more quirks to add, but hopefully other random people will start chipping away at it as a learning experience. It's been fun.
I am using latest kernel 5.16.15
Is there a way to add your patch to the current kernel and recompile for example ?
@ahmed-tasaly Try out this earlier patch or older iterations submitted to Patchwork, some of these probably apply fine on kernel 5.16:
v0: https://raw.githubusercontent.com/void-linux/void-packages/be587c070716d820eceee2377f966874ae51eb67/srcpkgs/linux5.15/patches/btusb-quirk-HCI_FLT_CLEAR_ALL.patchv1: https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/v2: https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/v3: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
@ahmed-tasaly Try out this earlier patch or older iterations submitted to Patchwork, some of these probably apply fine on kernel 5.16:
* `v0`: _https://raw.githubusercontent.com/void-linux/void-packages/be587c070716d820eceee2377f966874ae51eb67/srcpkgs/linux5.15/patches/btusb-quirk-HCI_FLT_CLEAR_ALL.patch_ * `v1`: _https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/_ * `v2`: _https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/_ * `v3`: _https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/_
can you tell me the instructions of patching the kernel by this patch
because I have spent serveral hours trying to figure this out but I couldnt
@ahmed-tasaly You can probably use the script from this Gist with the different/newer patch you want to apply: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07/545f26d353da9c146a8f4d04ff89efa9094dcacc
There's also this handy guide that also applies for the most part: https://old.reddit.com/r/AnnePro/comments/e76ij8/csr_40_bluetooth_dongle_on_linux/
Kernel 5.13.1 already had the patch (I downloaded it here)
But when I copy the patched driver, bluetooth module can't be enabled like this. Does anyone here has any idea?
$ modprobe btusb
modprobe: ERROR: could not insert 'btusb': Invalid argument
In step make -C $name oldconfig, should I choose default for all?
I compiled bluetooth-next, and tried using that. My dongle is still not working and the dmesg log is as follows:
rein ~ $ sudo dmesg | grep Bluetooth
[ 8.549642] Bluetooth: Core ver 2.22
[ 8.549661] Bluetooth: HCI device and connection manager initialized
[ 8.549664] Bluetooth: HCI socket layer initialized
[ 8.549666] Bluetooth: L2CAP socket layer initialized
[ 8.549668] Bluetooth: SCO socket layer initialized
[ 8.589852] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 8.589858] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 9.063531] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 9.063534] Bluetooth: BNEP filters: protocol multicast
[ 9.063537] Bluetooth: BNEP socket layer initialized
[ 11.340353] Bluetooth: hci0: command 0x0c01 tx timeout
[ 11.340354] Bluetooth: hci0: Opcode 0x c01 failed: -110
@LevitatingBusinessMan Dropping a link of a place where the dongle is sold or posting photos of the thing as shown above helps. It's a mishmash of variants, so we need to narrow down what's fixed and what not; there are no silver bullets, it's going to be a continuous trickle of quirks. See the comments above for ways of dumping more information via btmon, btusb and the like.
Here's a great report: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07?permalink_comment_id=4031963#gistcomment-4031963
@LevitatingBusinessMan Dropping a link of a place where the dongle is sold or posting photos of the thing as shown above helps. It's a mishmash of variants, so we need to narrow down what's fixed and what not; there are no silver bullets, it's going to be a continuous trickle of quirks. See the comments above for ways of dumping more information via
btmon,btusband the like.
I also have a bbs.archlinux.org forum post going on here.
The dongle in question is sold here.
It came with a little install disc for the rtl8761b driver (for windows).
I am not entirely sure how to get btmon to read anything. But if you give instructions I'll send any data that might be of help.
Edit: btmon output after I plugged the device in.
@LevitatingBusinessMan The latest patch was aimed to fix an identical V5.0-marked dongle with exactly the same plastic shell. Now it works correctly. As you can see we need internal photos of the PCB and chip, as well as the IDs if we ever want to classify them and make some sense out of them.
@Swyter Hmm then shouldn't it work for me? Maybe I am doing something wrong?
I'll try to crack it open but it doesn't seem easy, and I've never taken a usb device like this apart before.
@LevitatingBusinessMan Either the insides are different or they don't get along with certain USB ports/controllers. Try deleting these lines and recompiling your bluetooth-next kernel. Does that work?
@LevitatingBusinessMan Either the insides are different or they don't get along with certain USB ports/controllers. Try deleting these lines and recompiling your
bluetooth-nextkernel. Does that work?
It does not.
[ 9.378832] Bluetooth: Core ver 2.22
[ 9.378870] Bluetooth: HCI device and connection manager initialized
[ 9.378874] Bluetooth: HCI socket layer initialized
[ 9.378876] Bluetooth: L2CAP socket layer initialized
[ 9.378879] Bluetooth: SCO socket layer initialized
[ 9.600790] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 10.821114] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 10.821117] Bluetooth: BNEP filters: protocol multicast
[ 10.821121] Bluetooth: BNEP socket layer initialized
[ 12.403740] Bluetooth: hci0: Opcode 0x c01 failed: -110
[ 12.403760] Bluetooth: hci0: command tx timeout
However the dmesg logs are slightly different
@LevitatingBusinessMan Thanks for the photos, yeah, the PCB and innards seem to be completely different compared to mine, the one that now works. My chip is marked with a UG8413. Seemingly same enclosure and features.
@LevitatingBusinessMan You can try logging what the dongle does by running sudo btmon before plugging the thing. It should show everything and where it stops. In any case the rtl8761b mention is more than a really good hint. So thanks for that, and for testing the other thing, that narrows it down and helps a lot.
@LevitatingBusinessMan Sorry, there are so many reports that it's hard to follow who posts what. Because this one seems like a completely different vendor I would try deleting quirks one by one (the stuff surrounding the CSR lines from before) and see if anything helps. Try deleting the power management stuff, too.
That log is very useful to isolate any future codepaths to those models, but I don't see any HCI failures, just a bunch of reconnects. HCI events (responses from what we ask the dongle to do) causing the controller to go nuts.
Not that I know what I'm doing, I'm just another user fumbling around. ¯\_(ツ)_/¯
@LevitatingBusinessMan Okay, took another good look at the whole thing.
This is very interesting, seems like the problem is that the Realtek controller isn't initializing and needs firmware, you said in the Arch forum thread that you tried hex-editing, but the VID/PID here are different: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1955916/comments/21
Edit this line and replace the BTUSB_CSR with BTUSB_REALTEK|BTUSB_WIDEBAND_SPEECH and then copy the firmware files as instructed in the Launchpad comment: https://github.com/bluez/bluetooth-next/blob/4afc6c7435575398b4a3d045ccc8a8b1eab02fe9/drivers/bluetooth/btusb.c#L178
Maybe that does the trick. It's a hack, though.
(PS: I don't know why these Chinese companies like to squat specifically on this darn VID/PID combination for every dongle on Earth. Why not reuse some other Realtek PID to make Windows PnP driver autoinstall work. ¯\_(ツ)_/¯)
(I would guess windows XP didn't have all that much diversity of drivers)
sudo dmesg | grep Bluetooth
[ 25.827958] Bluetooth: Core ver 2.22
[ 25.827987] Bluetooth: HCI device and connection manager initialized
[ 25.827990] Bluetooth: HCI socket layer initialized
[ 25.827991] Bluetooth: L2CAP socket layer initialized
[ 25.827994] Bluetooth: SCO socket layer initialized
[ 33.198651] Bluetooth: hci0: RTL: examining hci_ver=09 hci_rev=0001 lmp_ver=09 lmp_subver=0001
[ 33.247119] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 33.247122] Bluetooth: BNEP filters: protocol multicast
[ 33.247126] Bluetooth: BNEP socket layer initialized
[ 33.407606] Bluetooth: hci0: RTL: examining hci_ver=09 hci_rev=0001 lmp_ver=09 lmp_subver=0001
[ 33.407616] Bluetooth: hci0: RTL: unknown IC info, lmp subver 0001, hci rev 0001, hci ver 0009
[ 33.407619] Bluetooth: hci0: RTL: assuming no firmware upload needed
[ 36.300103] Bluetooth: hci0: command 0x0c01 tx timeout
[ 36.303733] Bluetooth: hci0: Opcode 0x c01 failed: -110
With:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50df417207af..34203a216cd9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -175,7 +175,7 @@ MODULE_DEVICE_TABLE(usb, btusb_table);
static const struct usb_device_id blacklist_table[] = {
/* CSR BlueCore devices */
- { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_CSR },
+ { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_REALTEK|BTUSB_WIDEBAND_SPEECH },
/* Broadcom BCM2033 without firmware */
{ USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE },(PS: I don't know why these Chinese companies like to squat specifically on this darn VID/PID combination for every dongle on Earth. Why not reuse some other Realtek PID to make Windows PnP driver autoinstall work. ¯_(ツ)_/¯)
FYI this dongle did work automatically when I plugged it into windows.
Edit: Do I also install rtl8761usb(-dkms)?
@LevitatingBusinessMan What's the driver running under Windows? I'm guessing it's the generic one.
Took a look at the proprietary Linux Realtek driver and it's unlikely it's going to bind, seeing as they use the LMP subver field for their internal "project" ID. So, for the RTL8761X that field should be 0x8761 instead of your 0x0001. Even for an early RTL8723A (the only which doesn't match) the code is 0x1200. Also, the HCI rev field sometimes stores the letter of the project; 0x000a for the RTL8761A, 0x000d for RTL8723D and so on. Yours is also 0x0001.
So, it seems unlikely it's an actual Realtek chip. Sounds like a seller lie to me.
Another thing. The kernel says 8761B is the UART/laptop version, for the USB version of that chip it probably should be the 8761A, but if we look at the datasheet it says that the RTL8761BTV is the UART and RTL8761BUV the USB version. So make of that what you will. See:
- https://github.com/bluez/bluetooth-next/blob/4afc6c7435575398b4a3d045ccc8a8b1eab02fe9/drivers/bluetooth/btrtl.c#L137
- https://datasheet.lcsc.com/lcsc/2109131630_Realtek-Semicon-RTL8761BUV-CG_C2687140.pdf
The Launchpad hack works because the mainline Realtek driver only has a VID/PID whitelist in btusb to mark devices as Realtek-compatible, and btrtl then matches by LMP subver (=0x8761) and so on. On the other hand you have the external GPL Realtek driver, which does include the USB product ID in the list. Take a look at the two first elements of each line, which are pid and lmp_sub:
{0xA761, 0x8761, "mp_rtl8761a_fw", "rtl8761au_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU only */
{0x818B, 0x8761, "mp_rtl8761a_fw", "rtl8761aw_fw", "rtl8761aw_config", NULL, 0}, /* RTL8761AW + 8192EU */
{0x818C, 0x8761, "mp_rtl8761a_fw", "rtl8761aw_fw", "rtl8761aw_config", NULL, 0}, /* RTL8761AW + 8192EU */
{0x8760, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8192EE */
{0xB761, 0x8761, "mp_rtl8761a_fw", "rtl8761au_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AUV only */
{0x8761, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8192EE for LI */
{0x8A60, 0x8761, "mp_rtl8761a_fw", "rtl8761au8812ae_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8812AE */
{0x3527, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8814AE */So a device with an unregistered ghetto vendor 2550 and PID 8761 will work once whitelisted in btusb, but the LMP thingie must match for it to be considered a legit chip, which in that case it was, and it did, but whoever made it didn't want to pay the USB-IF association US$6,000 annually for a number.
So yeah, it's a miracle anything works at all. It's a freaking mess of legit chips, counterfeit chips, legit but unregistered vendor ID'd chips and more horrors of the computer world. All under the same plastic case.
@Swyter Thanks for your research, for someone that claims to just be fumbling around you seem to know what's up. I had the purchase refunded and the dongle will be picked up again by the vendor tomorrow.
my btmon output
Bluetooth monitor ver 5.64
= Note: Linux version 5.16.16-arch1-1 (x86_64) 0.500959
= Note: Bluetooth subsystem version 2.22 0.500961
@ MGMT Open: bluetoothd (privileged) version 1.21 {0x0001} 0.500962
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0) [hci0] 6.856064
= Open Index: 00:00:00:00:00:00 [hci0] 6.856124
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 6.856277
> HCI Event: Command Complete (0x0e) plen 12 #2 [hci0] 6.857698
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 12576 (0x3120)
LMP version: Bluetooth 5.0 (0x09) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Reset (0x03|0x0003) plen 0 #3 [hci0] 11.979445
= Close Index: 00:00:00:00:00:00
[hci0] 22.005233
at the same time
the output of
dmesg | grep Bluetooth
[ 3.403370] Bluetooth: Core ver 2.22
[ 3.403409] Bluetooth: HCI device and connection manager initialized
[ 3.403414] Bluetooth: HCI socket layer initialized
[ 3.403417] Bluetooth: L2CAP socket layer initialized
[ 3.403422] Bluetooth: SCO socket layer initialized
[ 3.748036] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 5.392060] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 5.392063] Bluetooth: BNEP filters: protocol multicast
[ 5.392066] Bluetooth: BNEP socket layer initialized
[ 8.915575] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 14.035380] Bluetooth: hci0: setting interface failed (110)
[ 3146.055870] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 3151.177553] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 3156.297179] Bluetooth: hci0: setting interface failed (110)
Quick heads up, had some time today and sent
v3for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
I applied these v4 patches on linux 5.17.0
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time!
It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included.
Thank you so much for your great work.
Quick heads up, had some time today and sent
v3for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/I applied these
v4patches on linux 5.17.0https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/ https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time! It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included. Thank you so much for your great work.
How did you do that ?
Can you help me with the steps ?
thanks in advance
Quick heads up, had some time today and sent
v3for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/I applied these
v4patches on linux 5.17.0
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/ https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time! It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included. Thank you so much for your great work.How did you do that ? Can you help me with the steps ? thanks in advance
Just compile and install the latest kernel (5.17.1). It doesn't need any patches and it will work without any problems.
Never read through this whole long thread, but thanks so much senpai! I just updated to linux 5.17 and my dongle works now! I bought a metric ton of them (like 8 or whatever) on aliexpress because they were like 2€s and I keep losing my normal 10€ dongles. I knew it was a gamble from the beginning. I have read about how support for these devices is known problem and there are even blog articles with kernel patches. However, none seemed to cover this specific hardware version. What's worse, trying them in a windows virtual machine actually worked :( Anyways, you did it! I was so happy that I thought I just had to read through the git log and find out who fixie wixied this fucksy upsy!
P.S.: How did you get the kernel guys to respond to you? I have recently made my first kernel patch that even made it into their patchwork:
https://patchwork.kernel.org/project/linux-input/patch/b401e453-9c66-15e3-1a1d-21f33b7a64e8@gmail.com/
However so far, no one has actually made a single comment to me about it. I have no idea if they like or despise it and it doesn't even build against the current sources anymore...
Many thanks.
P.S.: How did you get the kernel guys to respond to you? I have recently made my first kernel patch that even made it into their patchwork: https://patchwork.kernel.org/project/linux-input/patch/b401e453-9c66-15e3-1a1d-21f33b7a64e8@gmail.com/ However so far, no one has actually made a single comment to me about it. I have no idea if they like or despise it and it doesn't even build against the current sources anymore...
That looks like a reasonable patch to me. Unfortunately the HID subsystem maintainers have been a bit overloaded lately. I would suggest rebasing the patch on 5.17 (or 5.18-rc1 when it is out) and then resending it, with a note that it is a resend because v1 did not get any replies.
I updated to linux 5.17, and my dongle is still not working :((
dmesg report:
[ 39.167468] usb 1-4: new full-speed USB device number 4 using xhci_hcd
[ 39.316166] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[ 39.316488] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 39.316491] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 39.316493] usb 1-4: Product: USB2.0-BT
[ 39.344509] Bluetooth: Core ver 2.22
[ 39.344536] NET: Registered PF_BLUETOOTH protocol family
[ 39.344551] Bluetooth: HCI device and connection manager initialized
[ 39.344554] Bluetooth: HCI socket layer initialized
[ 39.344557] Bluetooth: L2CAP socket layer initialized
[ 39.344560] Bluetooth: SCO socket layer initialized
[ 39.356119] usbcore: registered new interface driver btusb
[ 39.356687] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 39.356690] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 39.396406] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 39.396409] Bluetooth: BNEP filters: protocol multicast
[ 39.396412] Bluetooth: BNEP socket layer initialized
[ 42.119083] Bluetooth: hci0: command 0x0c01 tx timeout
[ 42.119314] Bluetooth: hci0: Opcode 0x c01 failed: -110
I plug another dongle which has exactly the same cover (CSR 4.0 on both), and it works.
dmesg report of second dongle:
[ 98.435150] usb 1-4: USB disconnect, device number 4
[ 103.387316] usb 1-4: new full-speed USB device number 5 using xhci_hcd
[ 103.536318] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[ 103.536759] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 103.536772] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 103.536778] usb 1-4: Product: USB2.0-BT
I updated to linux 5.17, and my dongle is still not working :(( dmesg report:
[ 39.167468] usb 1-4: new full-speed USB device number 4 using xhci_hcd [ 39.316166] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping [ 39.316488] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 39.316491] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 39.316493] usb 1-4: Product: USB2.0-BT [ 39.344509] Bluetooth: Core ver 2.22 [ 39.344536] NET: Registered PF_BLUETOOTH protocol family [ 39.344551] Bluetooth: HCI device and connection manager initialized [ 39.344554] Bluetooth: HCI socket layer initialized [ 39.344557] Bluetooth: L2CAP socket layer initialized [ 39.344560] Bluetooth: SCO socket layer initialized [ 39.356119] usbcore: registered new interface driver btusb [ 39.356687] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once... [ 39.356690] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround [ 39.396406] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 39.396409] Bluetooth: BNEP filters: protocol multicast [ 39.396412] Bluetooth: BNEP socket layer initialized [ 42.119083] Bluetooth: hci0: command 0x0c01 tx timeout [ 42.119314] Bluetooth: hci0: Opcode 0x c01 failed: -110I plug another dongle which has exactly the same housing (CSR 4.0 on both), and it works. dmesg report of second dongle:
[ 98.435150] usb 1-4: USB disconnect, device number 4 [ 103.387316] usb 1-4: new full-speed USB device number 5 using xhci_hcd [ 103.536318] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping [ 103.536759] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 103.536772] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 103.536778] usb 1-4: Product: USB2.0-BT
Linux 5.17 still needs the v4 patches to be applied manually. You should use Linux 5.17.1.
@huynp1999 If you read the conversation above with @LevitatingBusinessMan you will see that having the exact enclosure does not guarantee anything. The photos show completely different PCBs and chips, counterfeit vendors mix and mash. Please take a look at that and share the same kind of photos and information. It really helps a lot to identify the different dongle families, finding enough patterns to fix them in a generic fashion.
@MikuChan03 I have also sent four or five trivial patches to the input subsystem since early 2021 and unfortunately no maintainers from that team have reviewed or responded, even after being Acked or Reviewed by others. Even after resending them, as Hans says. I feel like they need more manpower, there's an absolute backlog of submissions going on there that are being bottlenecked at the review stage.
Linux 5.17 still needs the v4 patches to be applied manually. You should use Linux 5.17.1.
yes, I'm using 5.17.1
@Swyter oh ok, thank you for your support. I will take a look inside these dongles
the first one that doesn't work:
The second one that works:
additional information: the second one even works with lower kernel (i.e 5.4 or 4.x)
You guys are right, I didn't notice the massive amount of patches pilling up on them. I'll lay back a little and mention it in time.
Have a good one!
@huynp1999 First one you showed (that doesn't work) looks a lot like mine, which I also couldn't get to work.
Yeah, it's the same PCB revision and everything. Good to have better pics and the chip vendor name. So it was a Barrot Technology one masking as a CSR, and sold as a Realtek. Go figure.
Does the second one that works get detected as a clone? I wonder if the HCI revision and LMP subversion numbers match.
I'm checking with hciconfig -a and dmesg. The first one don't show anything about HCI and LMP
Result of the second one that works:
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches.
I just combined them and made it compatible with linux 5.15.x LTS.
It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ac90392cc..39b189b16 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
+ set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
@@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev)
/*
* Special workaround for these BT 4.0 chip clones, and potentially more:
*
- * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810)
+ * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012)
* - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709)
*
* These controllers are really messed-up.
*
* 1. Their bulk RX endpoint will never report any data unless
- * the device was suspended at least once (yes, really).
+ * the device was suspended at least once (yes, really).
* 2. They will not wakeup when autosuspended and receiving data
- * on their bulk RX endpoint from e.g. a keyboard or mouse
- * (IOW remote-wakeup support is broken for the bulk endpoint).
+ * on their bulk RX endpoint from e.g. a keyboard or mouse
+ * (IOW remote-wakeup support is broken for the bulk endpoint).
*
* To fix 1. enable runtime-suspend, force-suspend the
* HCI and then wake-it up by disabling runtime-suspend.
@@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
if (ret >= 0)
msleep(200);
else
- bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
+ bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround");
pm_runtime_forbid(&data->udev->dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 9ce46cb85..41f0026b6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -255,6 +255,16 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
+
+ /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with
+ * HCI_FLT_CLEAR_ALL are ignored and event filtering is
+ * completely avoided. A subset of the CSR controller
+ * clones struggle with this and instantly lock up.
+ *
+ * Note that devices using this must (separately) disable
+ * runtime suspend, because event filtering takes place there.
+ */
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 53f1b0801..4c7f748b8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt)
static void bredr_setup(struct hci_request *req)
{
+ struct hci_dev *hdev = req->hdev;
__le16 param;
__u8 flt_type;
@@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req)
/* Read Current IAC LAP */
hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL);
- /* Clear Event Filters */
- flt_type = HCI_FLT_CLEAR_ALL;
- hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ /* Clear Event Filters; some fake CSR controllers lock up after setting
+ * this type of filter, so avoid sending the request altogether.
+ */
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ {
+ flt_type = HCI_FLT_CLEAR_ALL;
+ hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ }
/* Connection accept timeout ~20 secs */
param = cpu_to_le16(0x7d00);
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 1d34d330a..35308de87 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance)
static void hci_req_clear_event_filter(struct hci_request *req)
{
struct hci_cp_set_event_filter f;
+ struct hci_dev *hdev = req->hdev;
+
+ if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
+ return;
- if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED))
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
return;
- if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
+ if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) {
memset(&f, 0, sizeof(f));
f.flt_type = HCI_FLT_CLEAR_ALL;
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
@@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req)
static void hci_req_set_event_filter(struct hci_request *req)
{
+ struct hci_dev *hdev = req->hdev;
struct bdaddr_list_with_flags *b;
struct hci_cp_set_event_filter f;
- struct hci_dev *hdev = req->hdev;
u8 scan = SCAN_DISABLED;
bool scanning = test_bit(HCI_PSCAN, &hdev->flags);
if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ return;
+
/* Always clear event filter when starting */
hci_req_clear_event_filter(req);
/drivers/bluetooth/btusb.c
Hi, can you please tell me how to apply this patch?
regards,
Paulo
Hello! I use kernel 5.17.5 but this adapter doesn't working. What's to do?
/drivers/bluetooth/btusb.c
Hi, can you please tell me how to apply this patch?
regards, Paulo
Copy and save the patch as a .diff file.
Get the latest linux 5.15.36 LTS source, unpack and cd to it.
apply the patch:
patch -p1 < /path/to/the/patch.diff
start compiling and then use the new kernel.
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч?
с уважением, ПаулоСкопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:
.diff``cdpatch -p1 < /path/to/the/patch.diffначните компиляцию, а затем используйте новое ядро.
Okay, where is patch?
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч?
с уважением, ПаулоСкопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:
.diffcd ``patch -p1 < /path/to/the/patch.diff
начните компиляцию, а затем используйте новое ядро.Okay, where is patch?
It's right up there in my earlier commets, can't you see?
Here's the comment's link
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч? с уважением, Пауло
Скопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:cd '' начните компиляцию, а затем используйте новое ядро.
.diff``patch -p1 < /path/to/the/patch.diffХорошо, где патч?
Это прямо там, в моих ранних комметах, не так ли? Вот ссылка на комментарий
Thank you!
I'm in the same boat with this little guy, tried everything listed here, also tried with the patches from a known bug listed on the arch linux wiki bluetooth page but couldn't even compile the kernel with those patches (https://bugzilla.kernel.org/show_bug.cgi?id=60824) here is some info if someone can help me out:
here are some outputs from my tries:
lsusb
Bus 001 Device 024: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
btmon
Bluetooth monitor ver 5.64
= Note: Linux version 5.15.32-1-MANJARO (x86_64) 0.181266
= Note: Bluetooth subsystem version 2.22 0.181268
= New Index: 00:00:00:00:00:00 (Primary,USB,hci1) [hci1] 0.181268
= New Index: 48:E2:44:F6:F3:F4 (Primary,USB,hci0) [hci0] 0.181269 # this one (wifi/tb card) is powered off
@ MGMT Open: bluetoothd (privileged) version 1.21
hciconfig -a
hci1: Type: Primary Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:14 acl:0 sco:0 events:1 errors:0
TX bytes:3 acl:0 sco:0 commands:2 errors:1
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: PERIPHERAL ACCEPT
hci0: Type: Primary Bus: USB
BD Address: 48:E2:44:F6:F3:F4 ACL MTU: 1021:8 SCO MTU: 64:1
DOWN
using manjaro latest lts kernel without patches:
mhwd-kernel -li
Currently running: 5.15.32-1-MANJARO (linux515)
sudo hciconfig hci1 up
Can't init device hci1: Connection timed out (110)
dmesg | grep Bluetooth
[68300.546822] Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[68305.731582] Bluetooth: hci1: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[68310.851263] Bluetooth: hci1: setting interface failed (110)
using manjaro latest lts kernel with the patch posted above:
mhwd-kernel -li
Currently running: 5.15.32-1-MANJARO (linux515)
sudo hciconfig hci0 up
Can't init device hci0: Connection timed out (110)
dmesg | grep Bluetooth
[ 4.701306] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 9.753582] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 14.873783] Bluetooth: hci0: setting interface failed (110)
using latest stable kernel (without manual patches):
mhwd-kernel -li
Currently running: 5.17.1-3-MANJARO (linux517)
hciconfig hci0 up
Can't init device hci0: Broken pipe (32)
dmesg | grep Bluetooth
[ 5.017199] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 10.176336] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 12.305840] Bluetooth: hci0: Opcode 0x c03 failed: -110
[ 258.608877] Bluetooth: hci0: CSR: Local version failed (-32)
using latest disposable manjaro kernel (5.17.7)
mhwd-kernel -li
Currently running: 5.17.7-1-MANJARO (linux517)
hciconfig hci0 up
Can't init device hci0: Broken pipe (32)
dmesg | grep Bluetooth
[ 4.579313] Bluetooth: Core ver 2.22
[ 4.579378] Bluetooth: HCI device and connection manager initialized
[ 4.579382] Bluetooth: HCI socket layer initialized
[ 4.579384] Bluetooth: L2CAP socket layer initialized
[ 4.579388] Bluetooth: SCO socket layer initialized
[ 4.794437] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 4.941822] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 4.941826] Bluetooth: BNEP filters: protocol multicast
[ 4.941831] Bluetooth: BNEP socket layer initialized
[ 9.959543] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 12.092630] Bluetooth: hci0: Opcode 0x c03 failed: -110
bonus round: just plugged it on windows, and it worked like a charm lol (with generic driver):
Mine's working with the kernel 5.10, it's working fine when connected to a typical bluetooth speaker or a single TWS but won't work properly when connected to a TWS (stereo), no sound at all..
Sorry, I have to remove my contact info from gist.
My initial purpose was to let people contact me if anybody finds some new fix/patch.
Everything I got is a ton of spam like "help me please to fix bluetooth dongle on linux [version]".
Have a good day, yall!
Hey :)
Is there any ETA for when the current working patch will be merged into the main kernel? I am currently on kernel version 5.18, and it does not work.. Alternatively is there anyone adding the patch to the AUR?
Hey :) Is there any ETA for when the current working patch will be merged into the main kernel? I am currently on kernel version 5.18, and it does not work.. Alternatively is there anyone adding the patch to the AUR?
There's no working patch at the moment.
Well, it's fixed for all the dongles I have and the ones I bought just to fix more Linux kernel issues. Everything I submitted has been merged.
I can't really justify buying a sack of random AliExpress dongles and wait months for them to arrive and cross my fingers so that the seller is kind enough to not swap the advertised PCB (which happened two months ago, getting specific controllers is crazy hard) just to submit more patches. I bought one of the Barrot ones that still don't work and ended up with a duplicate that worked out of the box already. Super great.
--
I'm just a random Linux user doing it as a hobby after arriving at the same place, there is no ETA. Be the change you want to see in the world, if everyone did what I did with the hardware they own everything would be fixed.
Just make the jump and learn, even if it's through hacks and experimentation it will help getting to the correct solution if you stick around. Often you can fix a dongle by commenting out something or submitting an one-liner.
Thank you for your work on this, @Swyter. You helped inspire me to compile the kernel for the first time and you got my dongle working. I really appreciate the time you took developing the patches and hanging out here answering questions.
I compilied kernel with this patch, but problem with Bluetooth didn't fixed.
System: Fedora Linux.
Compilied version: 5.15.70
There's no need to do anything now. Just tested kernel 5.17.1. The patches are already included and the dongle works fine.
Just compile and install the latest version (linux 5.17.1)
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: ahmed-tasaly ***@***.***>
Sent: Wednesday, March 30, 2022 1:55:25 PM
To: nevack ***@***.***>
Cc: Reza Talebi ***@***.***>; Comment ***@***.***>
Subject: Re: nevack/archived.md
@ahmed-tasaly commented on this gist.
________________________________
Quick heads up, had some time today and sent v3 for kernel review. We'll see if they like it: ***@***.***/
I applied these v4 patches on linux 5.17.0
***@***.***/ ***@***.***/
and now my dongle is working for the first time! It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included. Thank you so much for your great work.
How did you do that ?
Can you help me with the steps ?
thanks in advance
—
Reply to this email directly, view it on GitHub<https://gist.github.com/6b36b82d715dc025163d9e9124840a07#gistcomment-4115410>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGC4IZWDBKLVJPISL2SQ52TVCQMYLANCNFSM4MFANRSA>.
You are receiving this because you commented.Message ID: ***@***.***>
Have installed 5.17.1-051701-generic on Ubuntu 22.04.1 and still have the problem
lsusb: Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Have tried with 6.0.7-060007-generic and still same output
[ 3.776546] Bluetooth: Core ver 2.22
[ 3.776576] NET: Registered PF_BLUETOOTH protocol family
[ 3.776577] Bluetooth: HCI device and connection manager initialized
[ 3.776582] Bluetooth: HCI socket layer initialized
[ 3.776585] Bluetooth: L2CAP socket layer initialized
[ 3.776589] Bluetooth: SCO socket layer initialized
[ 3.859412] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 4.406985] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 4.406988] Bluetooth: BNEP filters: protocol multicast
[ 4.406992] Bluetooth: BNEP socket layer initialized
[ 9.019046] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 11.032916] Bluetooth: hci0: Opcode 0x c03 failed: -110
Did somebody solve this?
Got the same problems and outputs on Ubuntu 22.04.1 LTS.
My dongle CSR 8510 A10 works fine on windows 7 on Microsoft generic driver.
Tried kernels 5.15.0 and 5.19.16.
I`m running Fedora 37 with kernel 6.0.7-301, unmodified.
Also getting errors, it used to work just fine on Fedora 35 and on older kernels in other distros.
[ 15.034386] Bluetooth: Core ver 2.22
[ 15.034400] Bluetooth: HCI device and connection manager initialized
[ 15.034402] Bluetooth: HCI socket layer initialized
[ 15.034404] Bluetooth: L2CAP socket layer initialized
[ 15.034407] Bluetooth: SCO socket layer initialized
[ 15.825231] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 15.825235] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 15.825238] Bluetooth: hci0: HCI Delete Stored Link Key command is advertised, but not supported.
[ 15.825239] Bluetooth: hci0: HCI Set Event Filter command not supported.
[ 17.948972] Bluetooth: hci0: command 0x0c5a tx timeout
[ 17.949005] Bluetooth: hci0: Opcode 0x c5a failed: -110
[ 20.711035] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 20.711037] Bluetooth: BNEP filters: protocol multicast
[ 20.711041] Bluetooth: BNEP socket layer initialized
See here: https://bugzilla.kernel.org/show_bug.cgi?id=60824#c242
Submitted a patch series here: https://bugzilla.kernel.org/show_bug.cgi?id=60824#c243
There was another simultaneous conversation in the mailing list here: https://linuxlists.cc/l/15/linux-bluetooth/t/4663230/(regression)_cambridge_silicon_radio,_ltd_bluetooth_dongle_unusable_again_with_kernel_6.0#post4683596
In the end, Luiz merged 2 out of the 3 patches upstream. There's radio silence about the third one.
Subscribe to the Bugzilla ticket if you want to stay up to date.
The patch series talked above is currently empty: https://patchwork.kernel.org/project/bluetooth/list/?series=690177&state
I'd patch my own kernel if possible. This problem has kept me out of Linux entirely.
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);
Thank you! Worked on Ubuntu 22.04!
uname -r
5.15.64-bluetooth
How fascinating - on an earlier standard Ubuntu kernel, the one of these I have Just Worked (and worked better than the 1Mii B10 dongle that's supposed to be the gold standard for doing this on Linux!)
But on the 5.15 kernel, it doesn't. I am not sure I have the patience to patch it.
Try a more updated or newer kernel instead of patching manually. Ubuntu and Debian are notorious for being extremely slow when moving from one version to another. The fix exists, it just hasn't arrived yet to your door. Arch Linux got it in early December, for example.
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);Thank you! Worked on Ubuntu 22.04! uname -r 5.15.64-bluetooth
Hello, I tried this patch on my Raspberry OS aarch64 with kernel 5.15.89-v8 however it didn't work. My 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode). My usb is still down according to hciconfig. It doesn't work for arm?
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown in lsusb as:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I cleaned up the patch:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8c41c76..9632251 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
+ set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
@@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
if (ret >= 0)
msleep(200);
else
- bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
+ bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround");
pm_runtime_forbid(&data->udev->dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 9ce46cb..b97602a 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -255,6 +255,7 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bb84ff5..2a7af9a 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req)
/* Clear Event Filters */
flt_type = HCI_FLT_CLEAR_ALL;
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks))
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
/* Connection accept timeout ~20 secs */
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index c2db60a..39a871a 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req)
if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks))
+ return;
+
if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
memset(&f, 0, sizeof(f));
f.flt_type = HCI_FLT_CLEAR_ALL;
@@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req)
if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ return;
+
/* Always clear event filter when starting */
hci_req_clear_event_filter(req);Extract the linux-source archive corresponding to your kernel and do the following:
$ patch -p1 < csr-clean.patch
$ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules
$ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules
$ strip --strip-debug net/bluetooth/bluetooth.ko
$ strip --strip-debug drivers/bluetooth/btusb.koThen you can replace the old drivers in /usr/lib/modules/$(uname -r)/kernel with the new ones. Don't forget to backup the old files.
I compiled this patch 5.15 but unfortunately it didn't work for my dongle.
It works if you remove the reset code from the bluetooth driver, no patches affect to this adapter
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);
بخدا مسلمون نیستی رضا. یه راهنمای قدم به قدمی چیزی مینوشتی که یکی با معلومات ضعیف مثل من هم بتونه استفاده کنه این رو. من debian 11 kernel 5.10-0.22rt دارم. میتونی یکم ساده تر توضیح بدی باید چیکار کنم ؟
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown in
lsusbas:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)I cleaned up the patch:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8c41c76..9632251 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb..b97602a 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,7 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index bb84ff5..2a7af9a 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req) /* Clear Event Filters */ flt_type = HCI_FLT_CLEAR_ALL; + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); /* Connection accept timeout ~20 secs */ diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index c2db60a..39a871a 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req) if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) + return; + if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; @@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req) if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);Extract the
linux-sourcearchive corresponding to your kernel and do the following:$ patch -p1 < csr-clean.patch $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ strip --strip-debug net/bluetooth/bluetooth.ko $ strip --strip-debug drivers/bluetooth/btusb.koThen you can replace the old drivers in
/usr/lib/modules/$(uname -r)/kernelwith the new ones. Don't forget to backup the old files.
It worked for me, tanks.
I currently have kernel 5.15.0-78-generic
My archives copilled:
https://drive.google.com/drive/folders/1cn7CZZUWD4B8hi-y0RKCNZIo78Bw7wFV?usp=sharing
I backed up and replaced the files
btusb.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/drivers/bluetooth
bluetooth.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/net/bluetooth/
Tossing my picture in for others. Was anyone lucky enough to find the exact chip used or have a module where the markings aren't etched away and replaced with what I assume is a serial number or datecode?
It was advertised as a Bluetooth 4.0 radio and it supposedly has the Qualcomm CSR8510A10 chip inside of it, but I seriously doubt it.
Chip markings which seem meaningless of EAG435 with 24 pins total (Those little copper rectangles on the edge) and 13 pins soldered in a Quad Flat No-Lead (QFN) package.
Side view of chip with markings of 24Mhz crystal
CSR4.0 outer casing
Front of PCB with flash
2018.12.06
LV-B14-V1.0
Front of PCB with flash disabled
Back of PCB
Pinout so far: (Adding the pinout later. Beeping everything out currently.)
- Not soldered
- Soldered
- Soldered
- GND (Soldered)
- Vcc 5V (Soldered)
- Not soldered
- Not soldered
- Soldered
- Soldered
- Soldered
- BT Antenna (Soldered)
- Not soldered
- Not soldered
- Soldered
- Not soldered
- Soldered
- Soldered
- Not soldered
- Not soldered
- USB Data- (Soldered)
- USB Data+ (Soldered)
- Soldered
- Soldered
- Not soldered
Front of PCB corrected for skew and cropped. Original orientation
Back of PCB corrected for skew and cropped. Horizontally flipped
Color coded back of PCB corrected for skew and cropped. Horizontally flipped
Throughholes: Blue
Blind vias: Red
@JeffreyO Thanks a lot for going above and beyond with your teardown! I remember trying to find the actual Chinese ASIC vendor, which (unless one takes a microscope photo of the bare die) it's going to be hard, but there are mentions to companies like Barrot in the kernel, which may be a good start point for more shady stuff: https://elixir.bootlin.com/linux/latest/source/drivers/bluetooth/btusb.c#L2322
If someone tried to clone the CSR chips they haven't done it correctly. ¯\_(ツ)_/¯
Note that the Barrot based clones (mine at least) actually
have Barrot and some Barrot modelnr written on the IC.
@JeffreyO Thanks a lot for going above and beyond with your teardown! I remember trying to find the actual Chinese ASIC vendor, which (unless one takes a microscope photo of the bare die) it's going to be hard, but there are mentions to companies like Barrot in the kernel, which may be a good start point for more shady stuff: https://elixir.bootlin.com/linux/latest/source/drivers/bluetooth/btusb.c#L2322
If someone tried to clone the CSR chips they haven't done it correctly. ¯_(ツ)_/¯
Thank you. Also, for anyone wondering, there is a way to properly and nondestructively open up the USB dongle. I just gently pried it apart and wiggled it enough and was lucky not to break anything.
But, that's not the right way. The right way is that there's a clip in the USB part latching to the outside of the case. You press down on that and slide the dongle apart away from the metal. It should all come out in one piece.
To put it back together, you sandwich the plastic parts and the PCB back together and slide it into the metal part (Keep it mind that those 2 tiny divots in the metal are the clips. It only goes together one way.) while applying very light pressure to the clip. You should hear a click when everything is back together successfully.
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown inlsusbas:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I cleaned up the patch:diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8c41c76..9632251 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb..b97602a 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,7 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index bb84ff5..2a7af9a 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req) /* Clear Event Filters */ flt_type = HCI_FLT_CLEAR_ALL; + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); /* Connection accept timeout ~20 secs */ diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index c2db60a..39a871a 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req) if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) + return; + if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; @@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req) if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);Extract the
linux-sourcearchive corresponding to your kernel and do the following:$ patch -p1 < csr-clean.patch $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ strip --strip-debug net/bluetooth/bluetooth.ko $ strip --strip-debug drivers/bluetooth/btusb.koThen you can replace the old drivers in
/usr/lib/modules/$(uname -r)/kernelwith the new ones. Don't forget to backup the old files.It worked for me, tanks.
I currently have kernel 5.15.0-78-generic
My archives copilled: https://drive.google.com/drive/folders/1cn7CZZUWD4B8hi-y0RKCNZIo78Bw7wFV?usp=sharing
I backed up and replaced the files
btusb.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/drivers/bluetooth bluetooth.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/net/bluetooth/
I have no idea on how to apply those patches and I'm willing a lot do so as my usb dongle shows up with same name in lsusb. Is there any material or could you explain me in a simple manner so I can reproduce it myself for kernel 6.6.6-arch1-1?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi. That is an old kernel version; to backport the patch to older Linux versions remove the
HCI_QUIRK_BROKEN_ERR_DATA_REPORTINGline frombtusb.cand ignore thehci.h/hci_core.cchanges, as none of that had been implemented by then. After that it should work fine.