Related to Framework Desktop - Framework Community where I’ve been working to fix crashing issues on Linux with the MT7925 driver in the kernel, I’ve gone ahead and packaged my MT7925 WiFi driver fixes as a DKMS module, making it much easier to install and maintain. No more manually patching and rebuilding your kernel! Hopefully MediaTek and AMD can land these changes upstream and this won’t be necessary.
What This Fixes
Kernel panics with NULL pointer dereference in mt7925
System hangs during WiFi network switching
Mutex deadlocks during suspend/resume
Processes stuck in D state (uninterruptible sleep)
Requirements
Kernel 6.17 or newer (Fedora 42, Arch, CachyOS, Ubuntu 25.10+)
I have #ifdefs that should work for 6.17, 6.18, and 6.19-rc kernels
DKMS installed
Kernel headers for your running kernel
Clang + lld if your kernel was built with clang (Arch, CachyOS)
dkms status | grep mt76
# Should show: mt76-mt7925/1.0.0, <your-kernel>, x86_64: installed
lsmod | grep mt7925
# Should show mt7925e and related modules loaded
Automatic Kernel Updates
The best part: when you update your kernel, DKMS automatically rebuilds the patched modules. No manual intervention needed.
Uninstall
If you need to remove it:
cd mt7925/dkms
sudo ./uninstall.sh
This removes the DKMS package and restores the stock kernel modules.
For Older Kernels (Ubuntu 24.04, etc.)
If you’re on kernel < 6.17, the DKMS package won’t work due to missing kernel APIs. You’ll need to either:
Upgrade to a newer kernel
Apply the patches directly to your kernel source (see the kernels/ directory in the repo for version-specific patches). I can’t help you here because the older kernels are very different now but some of the fixes might apply
Despite that I had no issues with the wifi card, Fedora 43 KDE Plasma just made a ton of updates available. These included updates to MT7925 for both wifi and bluetooth.
Some of the patches apply to the MT7921. I have a MT7921 so I tried the patches.
They cause the laptop to hang, so just a warning to others, if you have a MT7921, do not use these patches.
I do not have a MT7925, so I cannot comment on those patches and the above comment only applies to the MT7921, and not the MT7925.
I just got the MT7921 shipped to me so I can debug the hang issue there. Someone else reported it too. There are two patches in the code path for MT7921. One is shared code between both drivers, and the other is where I’m trying to backport one of the fixes to that older Wifi 6E chip. Going to see if I can reproduce the hang issue myself so I can see what code path is still holding on to the lock. I suspect it’s some kind of recursion. That being said that chip has a bit less going since it doesn’t support MLO, so the chance of hitting these specific crashes and deadlocks, while entirely not zero, is far less likely on that chip. So probably don’t need my fixes if you are going ok on the MT7921. Some of these bugs in the MT7925 driver existed in the MT7921 driver when the newer driver forked from the older one so I know they are there.
I also got the even newer MT7927 chip shipped to me (Framework doesn’t sell this one). I’ve heard the new MT7927 is a bit of an even worse mess on Linux at the moment, so I want to see if there is anything I can do there. That new model supports 320mhz channel widths on 6ghz compared to the 160mhz channel widths on the MT7925. I’m hoping the firmware on the chip is a bit better too, and doesn’t suffer the same deauth back off issues with the APs ask for a temporary backoff that seems to piss these chips off to where they just completely reset.
If you are not hitting these bugs then you can probably avoid for now while I work to get these fixes upstremed. You are more likely to hit these crashes if you suspend/resume and lose a specific race with reconnecting (more aggravated with MLO), have an enterprise or mesh AP setup where you can roam a lot between AP with the same SSID or where those APs try to force your card to re-associate to a different AP on their own, or you have an Wifi 6E or 7 AP that supports the new MLO standard where you can connect on multiple frequencies simultaneously and aggregate your links.
Looks like Fedora 43 just updated to a 6.18 based kernel. Checking their kernel git they don’t have any specific fixes not in mainline for this driver or any wifi chipset so it still suffers from these bugs specifically and on my Fedora 43 install where I tested my DKMS package I can reproduce these issues in under 5 minutes just moving around my building and roaming. The bug fixes that you might see from Fedora 42 to 43 kernels (they went from a 6.17 to a 6.18 based kernel) were some fixes around some regulatory domain setup in the driver, so allowing for the correct channels to be used for your country. No real crashing bugs fixed between those versions.
I’m pretty sure I found the issue for the MT7921 and running though doing some tests, but if you can this would help me a ton so I can verify that I’m fixing the same issue.
This will dump the kernel log of relevant lines for me for a previous boot if you were forced to reboot:
Or if you feel comfortable sending me a full kernel log from a previous boot where it locked up that would be awesome. Can me a DM or an email zac (at) zacbowling.com.
I’ve made a bunch of updates so that the DKMS module works properly after rebooting (if you are using that instead of the patches) and found some even more bugs. Up to 21 patches now in my patchset. Things are shockingly more stable for me.
If you installed earlier, I suggest doing a git pull on that repo checkout and rerunning the sudo ./install.sh script in the dkms directory.
Holy shit. I found another bug/quirk in the firmware, but it’s trivial to work around.
I noticed that I was never getting a 6ghz connection on my 160mhz wide channels I had open, or even getting a tri-band MLO connection stable. Now that I managed to get most of the MLO crashes fixed, I can work to get more MLO connections to connect. Except I can’t control that easily from the kernel. Firmware picks which channels to connect to.
But what worked was resetting the firmware to even consider connecting to 6ghz, switching the regulatory domain to a country that allows indoor 6ghz, and then back to the US, and suddenly it connects on 2.4ghz, 5ghz, and 6ghz for me. First time ever. And it seems to allow it after toggling the regulatory domain away and back seems to reset the internal logic in the wifi firmware.
Sticking this in the script early on to switch to Korea and back, and I’m getting 1.4gbps down with my aggregate connection.
sudo iw reg set KR && sleep 1 && sudo iw reg set US
Interface reports 2.4GB/s connection link possible, and that matches the AP’s backhaul link speed for my Unifi 7 Pro AP. That’s wild. That’s a 50% increase in the speed I was getting before over wifi.
Things are shockingly more stable for me.