[TRACKING] Unstable and unreliable WLAN RZ616/MT7922 [FW13 AMD DIY]

One more thing @lbkNhubert: If you are on 11th gen Intel, don’t you have an AX200/AX210 chip? Did you swap it with an mt7922?

@Ceremony - you are correct regarding the card. I swapped out the ax210 for the mt7922 in order to make use of the 6e band(s).

but… the AX210 is a 6e card? Did you mean AX200?

No, on the 11th Gen there is an issue with newer kernels that causes the 6e band(s) to be disabled.

Well, while it does work on my new Endeavour OS on a fresh boot, the slow transfer speed issue persists.
It pops up real often, while dmesg doesn’t show any mt7922/wlan0 issues.

I am swapping it with my old AX210 now, as that one was reliable in my previous laptop.

Running into the same issue here with Manjaro Gnome on Kernel 6.5.11 on my FW13 AMD DIY: there’s a ~20-30s delay post graphical boot/GDM login to get the mt7921e to show up and I have the same messages in dmesg:

[   10.873751] mt7921e 0000:01:00.0: not ready 1023ms after FLR; waiting
[   11.914400] mt7921e 0000:01:00.0: not ready 2047ms after FLR; waiting
[   14.020826] mt7921e 0000:01:00.0: not ready 4095ms after FLR; waiting
[   18.287488] mt7921e 0000:01:00.0: not ready 8191ms after FLR; waiting
[   26.607311] mt7921e 0000:01:00.0: not ready 16383ms after FLR; waiting
[   44.100756] mt7921e 0000:01:00.0: not ready 32767ms after FLR; waiting
[   78.234430] mt7921e 0000:01:00.0: not ready 65535ms after FLR; giving up
[   78.387363] mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
[   78.410109] mt7921e 0000:01:00.0: ASIC revision: 79220010
[   78.488252] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20230627143702a
[   78.864614] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20230627143946
[   79.952194] mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0

Note that this behavior is NOT systematic, it happens from time to time after certain reboots, hard to predict when or what triggers this.

Hi, let me join the party:

I have a different error in dmesg, but apart from that everything you guys say here resonates a lot with me. Especially the hard-to-reproduce part.
Sometimes it works just fine for entire sessions. Then I reboot/shutdown, and on the next one it’s completely useless (in my case the authentication to the base station times out).
There seems to be some correlation with the router (I have a TP-Link Archer C80 - no WiFi 6 on that one). Because on other APs (my ISP’s router and my Pixel 8 Pro’s hotspot) it works flawlessly and consistenly so.

With my previous laptop I had to stop taking firmware updates for my AX201 because it would destroy bandwidth whenever my BT earbuds were also connected (and that was an Intel board), now this…

Hardware is hard nowadays

Also experiencing sudden slowdowns/flakiness on FW13 AMD DIY with an AX1800. Dunno what’s going on.

This thread has some things that you might try to alleviate this: Poor Wi-Fi performance with AMD RZ616 - #4 by Mario_Limonciello

Hi @Ceremony,

As @lbkNhubert indicated via Mario:

I did locate what I believe was the patch in question.

https://patchwork.kernel.org/project/linux-wireless/patch/20231212090852.162787-1-mario.limonciello@amd.com/

Now, here is what I would suggest trying to see if it provides any relief.

Grab your device name (on Ubuntu, you will need to apt install iw):

iw dev | grep Interface | awk '{print $2}'

With that interface name, use nano/gedit or whichever editor you feel comfortable with:

sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

edit 3 into 2, save the file.

Reboot

Open the terminal back up again, check your power save status:

iw dev <interface-name> get power_save

You should see Power save: off

Now, this may not necessarily help. On my own WAP, I am not seeing this issue and I have kept power save on.

Internally, our engineers have had success disabling power saving on their 6E networks.

3 Likes

Same situation and configuration here. So far I haven’t found a solution, and unfortunately the tip with the adjusted configuration doesn’t work either. The WLAN card is not recognized for approx 20 to 30 seconds after login.

$ iw dev <interface-name> get power_save
command failed: No such device (-19)

And the dmesg output looks like this:

[   76.490501] mt7921e 0000:01:00.0: not ready 65535ms after FLR; giving up
[   76.644294] mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
[   76.660565] mt7921e 0000:01:00.0: ASIC revision: 79220010
[   76.745805] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a
[   77.118386] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441
[   78.253446] mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0

After a while, the WiFi card appears in the system, connects to the network and the output looks like this:

$ iw dev <interface-name> get power_save
Power save: off

So I guess it doesn’t necessarily have to do with the power settings of the WLAN card.

Is this Ubuntu by chance? If so, I will be filing this bug Tues.

1 Like

It’s Manjaro, not Ubuntu.

Hi! I have the same issue on Manjaro. My dmseg shows the same errors. Just wanted to add that this problem doesn’t happen when I reboot; only on a cold start.

1 Like

Manjaro users, if this is the same issue, this will come from this here if it’s the same issue.

for interface in $(iw dev | awk '/Interface/ {print $2}'); do iw dev "$interface" get power_save; done

Sorry, do you mean that the updated firmware introduced the bug?

Sorry, let me clarify a bit.

  • We have done zero testing on Manjaro for Mediatek, so this is speculative.

  • On tested distros Ubuntu 22.04.3 and Fedora 39, we are dealing with a Mediatek firmware bug that created slow down experienced by some users. Ubuntu is updating this, Fedora already has (when you’re updated with dnf). For other distros, this will depend on each distro maintainer to introduce this.

  • I suspect that the issue described here, it likely related and potentially addressed by this update. Since we do not test outside of officially tested distros due to available cycles, fastest way to a great experience is to either keep updating your distro of choice.

3 Likes

Got it, thanks!

1 Like

I’m currently using KDE Neon on a Lenovo Ideapad 5 14APH8 (6.5.0-15-generic kernel) which uses the same SOC and wifi module. Have similarly unstable WIFI.

Swapping the firmware following this post ([RESPONDED] Slow Wi-Fi on AMD 7040 with Ubuntu 22.04) seems to have improved the dropped connections BUT I’m still getting the odd dropped packet (running $ping 1.1.1.1 -q -O) but nothing like minutes of consequtive dropped packets.