I received my framework just yesterday and experience trouble with the included “AMD RZ616” or rather Mediathek MT7922 wifi card:
After booting, WLAN is usually not available right away. Looking into dmesg shows the following:
[ 9.890435] mt7921e 0000:01:00.0: not ready 1023ms after FLR; waiting
[ 10.930403] mt7921e 0000:01:00.0: not ready 2047ms after FLR; waiting
[ 13.170400] mt7921e 0000:01:00.0: not ready 4095ms after FLR; waiting
[ 17.437405] mt7921e 0000:01:00.0: not ready 8191ms after FLR; waiting
[ 25.757109] mt7921e 0000:01:00.0: not ready 16383ms after FLR; waiting
While the wlan-half remains unavailable, bluetooth works just fine… After a while, WLAN starts working as well:
Looking into the issue, some other laptops seem to share this issue, so it doesn’t seem to be a framework specific issue, but a common issue with this subpar mediatek chip/driver combination.
From time to time, wlan also becomes unbearably slow. disconnecting and reconnecting usually fixes this issue. I haven’t found a reliable way to reproduce that issue though…
I borrowed an Intel AX210 and experienced none of these issues…
I am currently running running latest stable Manjaro (KDE edition) and tried the previous 6.5.11 and last 6.6.1 kernel: same difference.
Has anyone else these issues with their AMD framework? anyone managed to fix or circumvent these wlan issues?
In the 3 days I’ve had the machine (Fedora 39) the mediatek WLAN has been flawless (edit: checked logs - no instances of the not ready errors). In fact, so far I haven’t experienced a weird issue I have been having with an older 11 gen machine (Intel AX210) on the same WLAN.
Having said that, it’s not inconceivable that the particular WLAN could be a variable. It does also use a Mediatek radio, for whatever that may matter. The AP is currently configured on a 5GHz DFS channel (106) in 80MHz ax mode.
Either way, if you haven’t, re-seating the WLAN adapter is probably worth trying.
I tried reseating, but it didn’t change anything. also it looked fine in its socket, not skewed or anything.
as for the delayed availability of the WLAN portion: it is not always the case. sometimes, it works right away, tho not always. i’d say its about 30% chance for it to work right away?
I also replicated it in the manjaro live distro installer… so it isn’t caused by any configuration to my system…
If this persists after re-seating then I think it’s support ticket time for a replacement.
Edit: just noticed you’re on Manjaro. Just for completeness as support will probably ask for it anyway, can you reproduce with a supported version of Fedora or Ubuntu live image USB?
I tested ubuntu 22 LTS (kernel 6.2) and 23 (kernel 6.5) live images: after 5 tries each, the initial issue didn’t pop up.
So back to testing my current manjaro setup: issue popped up reliably with both kernel 6.6 and 6.5, but not with 6.1 (LTS)… ill stick with 6.1 for now and see if the bandwidth issue also pops up.
@Ceremony your log entries also reminded me of this thread, issue there was resolved in the kernel as of 6.5.7. Your use case is different (no dock involved) but I wonder if that or some similar issue is at play in the kernel:
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.
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…