I use the internal Bluetooth on the motherboard, which comes with the AX200 WiFi chip. I have the provided antenna attached. It was working and then just stopped.
Here are the details for the second machine with the issue:
I looked at that article and it seemed mostly to be about getting Bluetooth installed and working, but it was already working. It was working fine on these two machines (five now, three machines my friends are running Manjaro on with the Intel AX200 Bluetooth are having issues, too) but then it stopped working after the most recent set of updates.
I am trying to figure out why it stopped working. I have access to two machines with AX200 Bluetooth issues and both stopped when the same patches were applied, so it’s not hardware.
If I run bluetoothctl list it doesn’t show any devices. Was there an update to the Intel Bluetooth driver in the latest kernel? Or maybe the microcode from Intel?
What can I do next? Where do I report this sort of issue if not here?
And compared it to what I have and I appear to have the firmware Intel says I am supposed to be using with the kernel I have, but that doesn’t mean that Intel hasn’t made a mistake here.
How do I establish where the issue is so I can report the problem to the appropriate party? It’s been over a week now that we’ve not had Bluetooth.
I fear that I am no help here. I don’t use bluetooth at all, although some devices can use it. Furthermore, I dislike it.
However… I cannot see any command which is called list here with bluetoothctl. Please educate yourself about this basic tool. Normally when the GUI doesn’t work, you can try to use the terminal and usually, you get more hints there.
Here is the help output for bluetoothctl, and it clearly shows a list option (in between transport and show:
bluetoothctl help
Menu main:
Available commands:
-------------------
advertise Advertise Options Submenu
monitor Advertisement Monitor Options Submenu
scan Scan Options Submenu
gatt Generic Attribute Submenu
admin Admin Policy Submenu
player Media Player Submenu
endpoint Media Endpoint Submenu
transport Media Transport Submenu
list List available controllers
show [ctrl] Controller information
select <ctrl> Select default controller
devices [Paired/Bonded/Trusted/Connected] List available devices, with an optional property as the filter
system-alias <name> Set controller alias
reset-alias Reset controller alias
power <on/off> Set controller power
pairable <on/off> Set controller pairable mode
discoverable <on/off> Set controller discoverable mode
discoverable-timeout [value] Set discoverable timeout
agent <on/off/capability> Enable/disable agent with given capability
default-agent Set agent as the default one
advertise <on/off/type> Enable/disable advertising with given type
set-alias <alias> Set device alias
scan <on/off/bredr/le> Scan for devices
info [dev] Device information
pair [dev] Pair with device
cancel-pairing [dev] Cancel pairing with device
trust [dev] Trust device
untrust [dev] Untrust device
block [dev] Block device
unblock [dev] Unblock device
remove <dev> Remove device
connect <dev> Connect device
disconnect [dev] Disconnect device
menu <name> Select submenu
version Display version
quit Quit program
exit Quit program
help Display help about this program
export Print environment variables
And even if linux-firmware-iwlwifi-git is not out of date, it forcefully uninstalls other, critical firmware packages for other hardware, at least from a common sense reading of what it says on the screen. And the firmware from that mini-package appears to be provided by linux-firmware anyway, rendering linux-firmware-iwlwifi-git pointless, at least as far as I can tell.
That AUR package is not made by kernel.org, but instead is made by an end user (elichai2) packaging a tiny sub-set of the kernel microcode git repo, and to install it I need to remove both amd-ucodeandlinux-firmware, essential packages for my system as far as I can tell.
And none of this answer my root question: how do I find out what’s wrong so I can report it in the right place to get this fixed? I have done what I was told:
I installed bluetoothctl and ran a command to list the hardware (which returned no results on any of the machines with this issue). What’s next?
I have provided the hardware details for the machines. I have listed the kernel versions. I have confirmed that the issue is consistent with this hardware and this kernel across multiple machines. I have included journalctl outputs.
And that error leads me to another post on this very forum from a user with broken Bluetooth begging for help:
I am with you: I would avoid Bluetooth if I had another option, but I need a wireless headset that also works with my phone, and Bluetooth is the only game in town that covers that niche. I only just started using it myself to allow me to talk and move around my office, and had been pleasantly surprised how well it worked… right up until it didn’t. I wish there was a “Bluetooth Pro” that worked over WiFi so at least there was an alternative to Bluetooth.
Intel Bluetooth and WiFi keep breaking on Manjaro, it seems. I have now found a litany of posts going back years that would seem to explain the terrible experience some of my friends and family have been having with Bluetooth and Intel AX200 Wireless on Manjaro (as I said, I am fairly new to Bluetooth and Manjaro, so this is the first time I have been impacted). When I search for the explicit error Reading Intel version command failed (-110) in the last month the only distros that seem to be impacted are Manjaro and Ubuntu.
I am not sure if the flakiness originates within Manjaro or upstream in Arch. While it also seems to impact Ubuntu, RedHat/Fedora don’t seem to have the same flakiness. Perhaps I need to have a deeper look at nobara.
And while this did “solve”-ish the issue, I can definitively prove this is not a hardware issue: the PN50 my mother runs Manjaro on has this issue with this kernel (6.2.12-1) as well. I installed linux61 and linux61-headers and then did the GRUB interrupt and manually booted to 6.1 and lo and behold Bluetooth was back. I would run the same test on my machine but it would break an AMD P-State experiment I am running.
This seems to be a code regression that creeps back into Manjaro (possibly via Arch upstream as I have found some historical issues with Arch and Bluetooth about this) and Ubuntu (possibly from their upstream). The current kernel for nobara is a little more recent than the Manjaro one so that’s not a direct comparison, but while this issue seems to crop up every three to six months on Manjaro and Ubuntu I just don’t see anything about it in the Fedora, Redhat or SUSE communities since 2019/2020.
I wonder if there is some kernel patch that Ubuntu and Manjaro both apply that perhaps Fedora, RHEL and SUSE don’t that causes this every now and again? And, how the hell do I report this, and who the hell do I report it to?
But, for now at least, I have a workaround. A hack, but it works. I guess I can make a service script to fix this on boot. I will have a tinker with what the absolute minimum delay I can get away with is.
My guess is that Ubuntu and Manjaro don’t have a patch for this, while Fedora, RHEL and SUSE patched it, or use an older kernel. You can file an issue here: Issues · Packages / Core / linux62 · GitLab So maybe they add a patch, but commonly the devs try to avoid custom patches. I am also unsure what kind of patch would be needed here. Since the kernel is as clean as possible, you would file an issue upstream to the kernel devs.
I’m the guy from the post you linked, I can confirm that it seems to have something to do with the kernel bug, after switching back to 5.10 it works. Weirdly after now switching back to 6.2 it still works fine. I will keep you updated if it breaks again but for now this seems to be a workaround that works.