[SOLVED] Using the AX210 with Linux on the Framework Laptop

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:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/bluetooth/btintel.c?id=v5.16-rc1&id2=v5.15

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. :slight_smile:

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 ""

everything is working well here on debian bookworm kernel version 5.15.0-3 including bluetooth and 150Mbps+ (fast.com test, so possible LAN is faster).

I’m dual booting Windows 11 and Fedora, I was having some problems with wifi not working in Fedora after rebooting from windows, what worked out was I had to turn off fast boot in Windows. link to a related article

Dang seems like I missed this thread

Has anyone seen the ax210 fail to come up with kernel 5.16 or 5.17?

I keep having to rmmod the iwlwifi kernel module, then modprobe it to get my WIFI to show up.

1 Like

The vPro version of this card is still crashing on Fedora and Arch for me. Arch, I have to restart iwd when coming back from sleep or booting up, where with Fedora, I had to manually remove some firmware to get the kernel to load a subpar (buggy, slow, etc.) version.

It works, just not well. I don’t see any activity upstream for this either.

1 Like

I don’t believe there is complete kernel support for the vPro version. I think the vPro requires some proprietary software for some of the features to work properly as well, for which I am not sure there is a Linux equivalent.

If you don’t need vPro for work, the non-Pro would be the way to go.

Did you manage to identify the issue? Wifi also refused to show up on my machine running Fedora 35 with kernel 5.16.20, and it turned out that I had to block firmware versions 67 and 66, which could be the same problem encountered here: https://bugs.archlinux.org/task/73387

My backup kernel 5.14.10 uses firmware 63 instead, and it works just fine.

If the issue persists, perhaps the information from running command “dmesg | grep iwlwifi” could help.

After tinkering with different firmware versions for my ax210 vpro I got stuck with version 62.
I tried different approaches to activate newer firmwares but to no avail, reloading iwlwifi module or restarts didn’t help.

Then after a complete shutdown I powered the framework on again and to my suprise the firmware 67 got loaded.
It could have been by accident but this was my observation. Maybe it helps others.

PS: DIY 1185G7, Fedora 35, latest Kernel 5.16.20.200