[SOLVED] Any way I can stop btusb from loading btintel

mdcclxv · 2023-12-11 00:06:49

Hi there,

I have a BT USB dongle, ASUS BT500. I also have an onboard BT chipset (the infamous AX200 from Intel, which is the reason I bought the dongle).
What is happening right now is that every time I reboot my system, the dongle hangs, hardware way, that is, no longer responding to any commands, although it is visible on lsusb.

I have a parallel Windows installation (with fastboot disabled) and when the dongle hangs it's no longer working in there as well. The only way to make it work again is to unplug it and plug it back in, under both Windows and Arch.

When I first installed it under Windows, it didn't work, kept failing in Device Manager. I found in ASUS' installation docs that I have to disable Intel's onboard BT from Device Manager. Works flawlessly that way under Windows, survives 100% to reboots. This is why I would like to stop btusb from loading btintel, see if I get any positive results.

I tried adding

install btintel /bin/true

to /etc/modprobe.d/, but then btusb no longer loads and dmesg shows

[  840.837190] btusb: Unknown symbol btintel_recv_event (err -2)
[  840.837240] btusb: Unknown symbol btintel_configure_setup (err -2)

Any way I can remove btintel from btusb's dependency list ?

Thanks in advance.

Last edited by mdcclxv (2023-12-20 22:49:23)

seth · 2023-12-11 14:44:43

Any way I can remove btintel from btusb's dependency list ?

The module will still try to use those functions.

Ideally, you'd just disable the BT chip in the BIOS/UEFI.
If that's absolutely not possible, you could add a udev rule to block the device, https://unix.stackexchange.com/question … nvironment

mdcclxv · 2023-12-11 19:57:21

The Intel chipset cannot be disabled from BIOS, there's no such option, that's the very first thing I looked for when I found out about ASUS' recommendations.

My suspicion is that some piece of Intel related code is actually causing the BT500 to hang. In Windows, when disabling something in Device Manager, it's the driver that is being disabled, not the hardware itself. I'm pretty sure we're not talking about conflicting hardware, but software messing up the hardware, at least on Windows.

I will try a udev rule and come back.

mdcclxv · 2023-12-12 10:42:31

I added the following udev rule:

ACTION=="add", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0029", ATTR{authorized}="0"

It makes no difference, the dongle still hangs between reboots. Confirmation the rule was applied:

~: cat /sys/bus/usb/devices/3-5/authorized 
0

No idea what I could try next

seth · 2023-12-12 14:16:57

Do you have the bluetooth modules in the initramfs?
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

mdcclxv · 2023-12-13 10:36:55

Here it is:

http://0x0.st/H35q.txt

Nice trick with the curl, btw

seth · 2023-12-13 13:26:51

Dec 13 12:33:07 amd kernel: usb 3-5: New USB device found, idVendor=8087, idProduct=0029, bcdDevice= 0.01
Dec 13 12:33:07 amd kernel: usb 3-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
…
Dec 13 12:33:08 amd (udev-worker)[393]: 3-5:1.1: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.1/authorized}, ignoring: No such file or directory
Dec 13 12:33:08 amd (udev-worker)[398]: 3-5:1.0: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.0/authorized}, ignoring: No such file or directory

Do you actually still get the errors when blacklisting btintel?

You could try adding

initcall_blacklist=btintel_configure_setup,btintel_setup_combined,btintel_recv_event

to the https://wiki.archlinux.org/title/Kernel_parameters *intead*.

Sanity check:

ls /usr/lib/firmware/rtl_bt/*8761*

mdcclxv · 2023-12-14 13:49:39

Dec 13 12:33:07 amd kernel: usb 3-5: New USB device found, idVendor=8087, idProduct=0029, bcdDevice= 0.01
Dec 13 12:33:07 amd kernel: usb 3-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
…
Dec 13 12:33:08 amd (udev-worker)[393]: 3-5:1.1: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.1/authorized}, ignoring: No such file or directory
Dec 13 12:33:08 amd (udev-worker)[398]: 3-5:1.0: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.0/authorized}, ignoring: No such file or directory

Do you actually still get the errors when blacklisting btintel?

The 40-.. file is an old rule, completely forgot about it, which I added when I installed my Arch to disable the onboard WiFi. Removed, as it is a duplicate now.

You could try adding
initcall_blacklist=btintel_configure_setup,btintel_setup_combined,btintel_recv_event
to the https://wiki.archlinux.org/title/Kernel_parameters *intead*.

I have no boot loader, so I had to edit the UEFI entry to add those params. But, alas, the dongle still hangs.

Sanity check:

ls /usr/lib/firmware/rtl_bt/*8761*

No idea why are we checking these:

~: ls -l /usr/lib/firmware/rtl_bt/*8761*
-rw-r--r-- 1 root root 38320 Nov 22 18:01 /usr/lib/firmware/rtl_bt/rtl8761a_fw.bin.zst
-rw-r--r-- 1 root root    38 Nov 22 18:01 /usr/lib/firmware/rtl_bt/rtl8761b_config.bin.zst
-rw-r--r-- 1 root root 30508 Nov 22 18:01 /usr/lib/firmware/rtl_bt/rtl8761b_fw.bin.zst
-rw-r--r-- 1 root root    19 Nov 22 18:01 /usr/lib/firmware/rtl_bt/rtl8761bu_config.bin.zst
-rw-r--r-- 1 root root 29947 Nov 22 18:01 /usr/lib/firmware/rtl_bt/rtl8761bu_fw.bin.zst

seth · 2023-12-14 13:53:25

Just to be sure they're there, b/c they don't show up in the journal, but I guess the adapter hangs before even that.
Does the journal indicate that the functions are blocked?

seth wrote:

Do you actually still get the errors when blacklisting btintel?

(Now, after un-authorizing the device)

mdcclxv · 2023-12-15 10:12:01

seth wrote:

Just to be sure they're there, b/c they don't show up in the journal, but I guess the adapter hangs before even that.
Does the journal indicate that the functions are blocked?

~: journalctl -b | grep btintel
Dec 14 12:54:04 amd kernel: Command line: root=UUID=bea56754-e0f6-4ecb-ace3-ccc734454406 resume=UUID=bea56754-e0f6-4ecb-ace3-ccc734454406 rw initrd=\initramfs-linux.img initcall_blacklist=btintel_configure_setup,btintel_setup_combined,btintel_recv_event
Dec 14 12:54:04 amd kernel: Kernel command line: root=UUID=bea56754-e0f6-4ecb-ace3-ccc734454406 resume=UUID=bea56754-e0f6-4ecb-ace3-ccc734454406 rw initrd=\initramfs-linux.img initcall_blacklist=btintel_configure_setup,btintel_setup_combined,btintel_recv_event
Dec 14 12:54:04 amd kernel: blacklisting initcall btintel_configure_setup
Dec 14 12:54:04 amd kernel: blacklisting initcall btintel_setup_combined
Dec 14 12:54:04 amd kernel: blacklisting initcall btintel_recv_event

seth wrote:
Do you actually still get the errors when blacklisting btintel?
(Now, after un-authorizing the device)

Yep:

~: journalctl -b | grep "3-5"
Dec 14 12:54:05 amd kernel: usb 3-5: new full-speed USB device number 4 using xhci_hcd
Dec 14 12:54:05 amd kernel: usb 3-5: New USB device found, idVendor=8087, idProduct=0029, bcdDevice= 0.01
Dec 14 12:54:05 amd kernel: usb 3-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Dec 14 12:54:06 amd (udev-worker)[433]: 3-5:1.0: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.0/authorized}, ignoring: No such file or directory
Dec 14 12:54:06 amd (udev-worker)[409]: 3-5:1.1: /etc/udev/rules.d/40-disable_builtin_radio.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3/usb3/3-5/3-5:1.1/authorized}, ignoring: No such file or directory

seth · 2023-12-15 14:20:08

No, what I meant was

[  840.837190] btusb: Unknown symbol btintel_recv_event (err -2)
[  840.837240] btusb: Unknown symbol btintel_configure_setup (err -2)

mdcclxv · 2023-12-16 00:11:47

seth wrote:

No, what I meant was

[  840.837190] btusb: Unknown symbol btintel_recv_event (err -2)
[  840.837240] btusb: Unknown symbol btintel_configure_setup (err -2)

Nope, they're gone.

seth · 2023-12-16 08:32:34

So you can this way also blacklist btintel (your origignal idea), but that doesn't help w/ the dongle?

mdcclxv · 2023-12-16 17:20:05

seth wrote:

So you can this way also blacklist btintel (your origignal idea), but that doesn't help w/ the dongle?

The bitter truth

I also tried

modprobe -r btusb

before rebooting, hoping this way the dongle won't be touched during the shutdown part of the reboot, same result.

Is there a way to "eject" the dongle before rebooting? This way at least I would know for sure that it's the init procedure that hangs the dongle, not the shutdown.

seth · 2023-12-16 18:38:56

Is there a way to "eject" the dongle before rebooting?

You mean to unplug it?
I don't think this is gonna help you, though.

What if you unplug the dongle, disable bluetoothd, reboot, run "dmesg -w" and then plug the dongle?
=> dmesg output and following "rfkill"?
Then https://wiki.archlinux.org/title/Blueto … leshooting and try to manually pair, at what point does dmesg start to yell errors at you?

mdcclxv · 2023-12-16 22:58:36

What if you unplug the dongle, disable bluetoothd, reboot, run "dmesg -w" and then plug the dongle?
=> dmesg output

[ 3699.839413] usb 3-2.1: new full-speed USB device number 8 using xhci_hcd
[ 3699.965412] usb 3-2.1: New USB device found, idVendor=0b05, idProduct=190e, bcdDevice= 2.00
[ 3699.965419] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3699.965422] usb 3-2.1: Product: ASUS USB-BT500
[ 3699.965424] usb 3-2.1: Manufacturer: Realtek
[ 3699.965425] usb 3-2.1: SerialNumber: 00E04C239987
[ 3700.010612] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[ 3700.011613] Bluetooth: hci0: RTL: rom_version status=0 version=1
[ 3700.011618] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
[ 3700.014555] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[ 3700.014709] Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210
[ 3700.162623] Bluetooth: hci0: RTL: fw version 0xdfc6d922

and following "rfkill"?

~: rfkill
ID TYPE      DEVICE      SOFT      HARD
 0 wlan      phy0     blocked unblocked
 1 bluetooth hci0   unblocked unblocked

The "problem" here is that if I plug the dongle after the system is up, it works with no issues. It hangs on a reboot.

Upon re-enabling and starting bluetooth I got this in dmesg's output:

[ 4353.206654] Bluetooth: hci0: Bad flag given (0x1) vs supported (0x0)

But then my BT keyboard connected just fine.

Again, the issue only happens on a reboot.

Last edited by mdcclxv (2023-12-16 22:58:54)

seth · 2023-12-17 09:59:54

That exclusive condition had kinda escaped me…

Dec 13 12:33:07 amd kernel: usb 3-2.1: Manufacturer: Realte!

looks like the dongle isn't fully initiated when polled.
Can you avoid this by stalling the boot (hanging out at the uefi/bootloader for a while)?

Don't block the intel BT and post the output of

lsusb -tv

Looks like the

Dec 13 12:33:06 amd kernel: usb 3-1: Product: Keychron K8 Pro

is on the same hub, can you afford the BT dongle a hub of its own or work w/o the keychron (replace it w/ $5 office supply)?

mdcclxv · 2023-12-17 19:06:32

You are a genius

Moving the dongle on a hub of its own seems to have fixed the issue, survives reboots and shutdowns/power-ons with btintel not blacklisted. Thanks a million!

So it was a hardware incompatibility after all. Should've listened to you more carefully.
My take is that ASUS' Windows driver is aware of this issue, knows how to recover from it and probably the Intel driver is messing up the recovery procedure.

As a side note, on my normal workflow the Keychron is the device using the dongle, so it's not connected to USB on my day-to-day usage.

Now I will start adding devices one by one to see exactly which one causes the problem.

mdcclxv · 2023-12-25 16:44:22

Just an update for whoever comes reading: the ASUS BT500 dongle doesn't do well together with any device on the same hub. I've tried connecting, one by one, every USB device I use on my machine, with the same result, BT500 doesn't survive reboots. As soon as I left it alone, works as expected. Nice job ASUS!

Arch Linux

#1 2023-12-11 00:06:49

[SOLVED] Any way I can stop btusb from loading btintel

#2 2023-12-11 14:44:43

Re: [SOLVED] Any way I can stop btusb from loading btintel

#3 2023-12-11 19:57:21

Re: [SOLVED] Any way I can stop btusb from loading btintel

#4 2023-12-12 10:42:31

Re: [SOLVED] Any way I can stop btusb from loading btintel

#5 2023-12-12 14:16:57

Re: [SOLVED] Any way I can stop btusb from loading btintel

#6 2023-12-13 10:36:55

Re: [SOLVED] Any way I can stop btusb from loading btintel

#7 2023-12-13 13:26:51

Re: [SOLVED] Any way I can stop btusb from loading btintel

#8 2023-12-14 13:49:39

Re: [SOLVED] Any way I can stop btusb from loading btintel

#9 2023-12-14 13:53:25

Re: [SOLVED] Any way I can stop btusb from loading btintel

#10 2023-12-15 10:12:01

Re: [SOLVED] Any way I can stop btusb from loading btintel

#11 2023-12-15 14:20:08

Re: [SOLVED] Any way I can stop btusb from loading btintel

#12 2023-12-16 00:11:47

Re: [SOLVED] Any way I can stop btusb from loading btintel

#13 2023-12-16 08:32:34

Re: [SOLVED] Any way I can stop btusb from loading btintel

#14 2023-12-16 17:20:05

Re: [SOLVED] Any way I can stop btusb from loading btintel

#15 2023-12-16 18:38:56

Re: [SOLVED] Any way I can stop btusb from loading btintel

#16 2023-12-16 22:58:36

Re: [SOLVED] Any way I can stop btusb from loading btintel

#17 2023-12-17 09:59:54

Re: [SOLVED] Any way I can stop btusb from loading btintel

#18 2023-12-17 19:06:32

Re: [SOLVED] Any way I can stop btusb from loading btintel

#19 2023-12-25 16:44:22

Re: [SOLVED] Any way I can stop btusb from loading btintel

Board footer