Hopefully I didn’t damage the connectors when installing them. The antenna wires were a bit long on my DIY and took many attempts to get them tucked.
Bluetooth is now working for me on Arch Linux with kernel 5.14.14.
Interesting… reboots were still resulting in no bluetooth controllers found for me on Arch/5.14.14 yesterday. Updated to 5.14.15 today (via pacman), still no dice. Cold boots are still working fine.
I’ve got a pretty basic setup, KDE with:
bluez 5.62-1
bluez-libs 5.62-1
bluez-qt 5.87.0-1
bluez-utils 5.62-1
Are you compiling the kernel yourself or running anything out of the ordinary?
After updating to the latest 5.14.16 kernel on Arch, bluetooth stopped working after both cold and warm boots. Rolling back to 5.14.15 at least got me functioning bluetooth again after a cold boot.
It didn’t even occur to me to run a speed test, because it was working fine, but when I saw the posts here, so I got to wondering.
This is out of the box running Pop OS Non-LTS, but I did actually upgrade to the beta version released a few days ago to see if it would fix the fingerprint reader (it did).
I can consistently get about 450Mbps up and down for speed test services hosted in Japan. My Macbook Pro seems to get slower (like 230) on average, but occasionally over 500.
Certainly more than 15 anyway.
(My connection is supposedly 2Gbps, but no WiFi can handle that…)
Oh, bluetooth is working in the sense that devices show up in a bluetooth scan, but I haven’t had the desire to actually pair anything yet.
shiruba@framework:~$ uname -a
Linux framework 5.13.0-7620-generic #20~1634827117~21.10~874b071 SMP Thu Oct 21 16:32:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
shiruba@framework:~$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="21.10"
BTW My Router is a Synology R2600
1 Like
Good news – according to this comment on the bug, the patch fixing the bluetooth bug has landed and will be included in an upcoming 5.15 release. 
1 Like
I’m on 5.15.2 and the bluetooth warm boot issue is still here. The newer comments in that thread seem to suggest the same.
The last post seem to indicate there’s a patch that works. It would be nice if it made it in 5.15 at some point, but my money’s on it being released with 5.16.
I rebuilt a custom Arch 5.15.2 kernel with this patch and I can confirm bluetooth is now working properly for me, I was never able to get bluetoothctl to find a controller at all until this patch, warm boot, cold boot, didn’t matter. I’m using the vPro version of the AX210 as well.
2 Likes
Unfortunately I do not yet have a Framework (perhaps once it will be available in my country, and with a larger screen and more I/O), however as I generally upgrade my WiFi with modules I order from Fenvi’s AliExpress store (they also sell on Amazon and Newegg, to my country it just makes more sense to order these from AliExpress), I am currently rocking an AX210 on my Lenovo IdeaPad 300-15ISK, an AX200 with Fenvi’s FV-102 M.2 to standard PCIe adapter on my desktop (Asus Z97 Pro-Gamer at the moment), and the rest of the family are using 9260 modules on their laptops and desktops (the latter with FV-102 adapters).
I use Solus, and I can confirm from my testing that when the regressions occurred, it affected everything from the 9260 to the AX210 (there were both WiFi and Bluetooth issues, not necessarily at the same time, and not necessarily the same exact issues between the different models), at least on Solus, and currently on 5.14.16 on Solus, there are no issues currently with any of them.
Looks like the patch didn’t make it into the v5.16-rc1:
2 Likes
Well, for what it’s worth, I’m running Arch and used this AUR package to build a kernel off the latest linux-next sources, which have picked up the change. I tested sleep/wake and bluetooth works fine! Hopefully it’ll be in a regular kernel soon, but till then, I think this works. 
4 Likes
Follow-up from my earlier posts about microcode errors during rescan under load: I’ve managed to workaround by setting modprobe config options iwlwifi disable_11ax=Y. Doing so I’m getting no errors and performance is as expected, but obviously 802.11ax (aka WiFi 6) is disabled, but 802.11ac works.
5 Likes
I can confirm this workaround resolves the issues. I only have AC access points so am not missing anything right now by disabling AX. Nice find!
1 Like
Follow-up from my earlier posts about microcode errors during rescan under load: Intel has provided a patch on the bug report that helps a lot if you need 802.11ax (so disabling it as in my other workaround is not ideal). See discussion on the ticket for more details.
2 Likes
This appears to be working now in 5.15.4 at least on Arch
1 Like
This was interesting.
I am using Mint 20.2, Cinnamon Edition. I have never tried to use a custom kernel build until now. Mint has had this configuration item in their update manager to see what kernel is in use, which are available from the Mint channels and to change to a different one if desired.
I followed the directions & it tells me I am on 5.13.0-22 & does not even list anything at the 5.15 (which is where Xanmod is at). This is despite the fact that I never saw any errors & I even saw an update (also successful).
I am pointing this out because that information seems to be wrong. If we run inxi -S I actually get the following output:
System: Host: leuresthes-f Kernel: 5.15.7-xanmod1 x86_64 bits: 64 Desktop: Cinnamon 5.0.7
Distro: Linux Mint 20.2 Uma
So I don’t know where that GUI item gets its information but it is incomplete and can be wrong.
Also, why can’t I do a code block on this forum?
@August_Pamplona Yeah, it won’t show kernels installed from external repositories, but what it does show shouldn’t be wrong. Please note that “Installed” does not mean currently in use. If you were using a non-custom kernel, it would tell you which one was in use at the top.
Yes, you are right. If I remember correctly, the one currently in use will be marked as “installed” as well as “active”. Looking closely, I do not have any labelled like that (due to this being a custom kernel).
Use three backticks around the code block. Example:
#!/bin/bash
systemctl -q is-active openvpn@* && echo -n "🔑" || echo -n ""