mt7925 also fine here for the most part on NixOS 6.15, although I did hit an intermittent probing issue, which seems to be fixed with the latest firmware:
Do you mean 6.15.1? I donât see 6.15.0 in the nix packages nor in the kernel mirrors.
I wonder if the router comes into play. Iâm on a BPI-R3 running OpenWrt.
Perhaps⌠Iâm on Mikrotik hAP ac2 (running RouterOS 6.49.18).
Iâm currently running 6.15, although 6.15.1 has just reached nixos-unstable, so will be updating.
I investigated the issue a bit further and found that for my setup, the regression is introduced in 6.14.3 (6.14.2 is the last version that works for me).
Also an interesting detail that I didnât notice because I didnât care about upload speed initially: on 6.14.3 I get around 16Mbps download and 300Mbps upload, and on 6.14.2 I get around 250Mbps download and 50Mbps upload. So on one version the download is bad but the upload is good, and vice-versa on the other version.
Reported my issue/findings here.
2 Likes
6.15.0
Just updated, now on 6.15.1, Wi-Fi speeds are the same as on 6.15.0 FWIW.
Between 6.14.2 and 6.14.3 several commits landed for the MediaTek 7925 which adjust things like powersave, MLO setup, etc (changelog here, search for âmt7925â and âmt76â).
As @serafean pointed out, itâs good to check firmware versions as well. Within the past two weeks, new WiFi (and Bluetooth) firmware was recently released (late May build date, link here). Possibly that may help if the performance is similar amongst all kernels post 6.14.2.
If AMD or mediatek (or anyone) releases buggy drivers for windows, framework canât do anything about it either. Case in point : recent nvidia drivers. None of the computer vendors, or game developers can do anything about that.
My view is that with Linux I at least have a chance to debug the issue, so I take that.
It canât work: those are no longer PCIe devices, but some intel cheapskate called CNVio(2) where only the radio is on the expansion card, and all the rest of the âwifi hardwareâ is prebaked on the chipset.
TLDR: donât even try intel cards ending 1.
2 Likes
I donât have the Framework Laptop 13", AMD AI 300 Series, so take this with a grain of salt. I actually saw improvement with upstream stable 6.14.3 kernel compared to upstream stable 6.14.2.
Testing info below, but generally, performance seemed to improve with successive kernel versions (yay, stabilizing!). 6.15.2 with May firmware performed the best, so hopefully this improvement translates to the Framework platforms as well 
My testing scenario includes the following:
- mt7925 radio in an Intel-based CPU system
- mt7996-based WiFi 7 AP (no MLO)
- AP configured to 40MHz at channel 36 (surprisingly unused where Iâm at)
- Station configured to WPA2, no PMF (802.11w)
- Kernels built from tagged versions in the Linux stable tree
- Single-direction, 1Gbps-configured
iperf3UDP traffic with 10 parallel streams (iperf3 --bind-dev wlan0 -b 1G -P 10 -u, add-Rto do opposite direction)
I tested each of the following kernels with mt7925 firmware from March, April, and May (available in the Linux firmware repo on kernel.org). I skipped over a few 6.14 kernels, as there really arenât many âmt76â or âmt7925â driver fixes/updates until 6.14.8 and 6.14.9 and none after.
- 6.14.2
- 6.14.3 (includes successive connection failing fix)
- 6.14.9 (includes IPv6 and multicast traffic drop fix)
- 6.15.2
For folks looking to reproduce or especially detailed info:
- Query driver and firmware information with
ethtool -i wlan0command (use-Sinstead for interface statistics) - Link rate and related information (MCS, NSS) can be queried using the
iw wlan0 linkcommand. Note that youâll need to get a recent version to display EHT (WiFi 7) information. I like running it in a loop likewatch -n .1 "iw wlan0 link" wpa_supplicantconfig below (wpa_supplicant -c wlan0.conf -i wlan0)- Using a secondary sniffer radio, saw that 6.14.2 would not do upload traffic with block ACKs (frame aggregation) with all firmware versions. 6.14.3 did, though, which seemingly explains the substantial increase in upload throughput.
# Only used if you're also using 'wpa_cli'
ctrl_interface=/var/run/wpa_supplicant
network={
# Need to use 'wpa_passphrase' to generate WPA2 'psk'
# e.g. 'wpa_passphrase ssid password'
ssid="ssid"
psk=XXXXXXX
# Can force to specific band using BSSID
#bssid=xx:xx:xx:xx:xx:xx
pairwise=CCMP
key_mgmt=WPA-PSK
ieee80211w=0
}
Yup, I have an older 13" Ryzen I purchased last year, no issues with it. Only the new AI 300.
Yeah the Intel AX210 NGW I got has WiFi 6E, which is fine for my needs. One thing I love about these laptops is I could upgrade down the line since their not soldered to the mobo.
My complaint is saying âofficial supportâ for Fedora, but having barely functional WiFi. The laptop also crashed when plugged into my thunderbolt adapter.
I think there just needs to be a little more clarity around the fact this is still fairly bleeding edge ATM.
I must say with the WiFi chip swapped, the system is super stable (still issues with thunderbolt though).
âofficial supportâ mainly means that if you contact support, or file a ticket, with Fedora frame.work will take a look at it. With Gentoo theyâll tell me to retest with Fedora.
2 Likes
You also wonât be told your device is out of warranty because you installed linux. Anyone who has used linux for any length of time knows months 1-6 after a new cpu is released is the time to buy it only if you 1) absolutely have to replace a device, 2) donât mind paper cuts, and/or 3) expect to troubleshoot and generally like doing that in order to help clean it up for everyone else.
If you donât have time for any of that you generally get last years model.
1 Like
Never had that issue with Dell or Lenovo/IBM 
Regardless, would be great if they had guidance on a particular kernel version that fully supported the new wifi chips and/or guidance around which routers/bands work better. Or a notice that current kernel / distro versions have spotty Wifi support at the moment.
If their documentation stated lack of support right-now, and recommended buying an Intel chip, I would have still bought the laptop and simply bought an Intel WiFi chip at the same time (as I eventually ended up doing after trouble-shooting).
Iâm in agreementâŚbut want to also add:
Post-6-months is still rather optimistic given how long various AMD bugs seem to be lingering. Personally, I stick with n-1 gen if stability is important. The FL12 with 13th gen U seems to be a good call on the stability and Linux support fronts.
Windows support has always been the 1st stop for any new consumer laptop release (except Apple). Donât think Iâve ever seen Linux being the first stop before WindowsâŚfor better or for worse.
1 Like
Agreed, that or similar maturing AMD chip.
I miss Boot Camp; a MacBook made an excellent Windows machine.
Agreed Windows gets the bulk of the pre-release testing but at the same time I have seen that delay dwindle. On release they are actually pretty comparable, and many bugs present on Linux are often mirrored in Windows. I used to stick to the one gen behind, but really donât think it is necessary anymore. Also AMD seems to suffer from a lot more issues in the mobile space than Intel on linux.
If you use a distro running a relatively current kernel (and mesa and stuff), if you run something else it is very much still a good idea.
It looks like the GPU still periodically crashes under kernel 6.15.4. At least it doesnât reboot the entire laptop anymore, just the desktop. Hereâs the log if it helps:
amdgpu: [gfxhub] page fault (src_id:0 ring:157 vmid:4 pasid:32775)
amdgpu: in process Discord pid 594558 thread Discord:cs0 pid 594580)
amdgpu: in page starting at address 0x0000800113409000 from client 10
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x0040113B
amdgpu: Faulty UTCL2 client ID: TCP (0x8)
amdgpu: MORE_FAULTS: 0x1
amdgpu: WALKER_ERROR: 0x5
amdgpu: PERMISSION_FAULTS: 0x3
amdgpu: MAPPING_ERROR: 0x1
amdgpu: RW: 0x0
amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:4 pasid:32775)
amdgpu: in process Discord pid 594558 thread Discord:cs0 pid 594580)
amdgpu: in page starting at address 0x000080011340a000 from client 10
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00401031
amdgpu: Faulty UTCL2 client ID: TCP (0x8)
amdgpu: MORE_FAULTS: 0x1
amdgpu: WALKER_ERROR: 0x0
amdgpu: PERMISSION_FAULTS: 0x3
amdgpu: MAPPING_ERROR: 0x0
amdgpu: RW: 0x0
(Moved over from the ubuntu thread because I now suspect this is a hardware problem.)