Thanks for posting but the logs got spammed a bit by your discord. These patches mostly just solve the driver from being able to crash your whole machine when it struggles and try to mitigate other issues that cause instability.
There are still some of the core issues are in the firmware of the wifi chip that I can’t fix since the wifi firmware is encrypted and don’t have visibility. What these patches will do though is handle when the firmware crashes and the wifi chip needs to be reset so that things can come back up quicky. There can also be other environmental or AP side issues that can cause issues.
MediaTek needs to fix those core issues but at least if wifi breaks you won’t lose work. If you can collect logs though, now I have a channel with MediaTek to feed them issues I’m seeing from the community when I can’t fix them at the driver level in the kernel.
I put a guide in the DKMS readme on on how to filter the messages from your system to ones that useful for a report.
Hello, I installed this Sefdrert MT7925 Wifi/Bluetooth Card purchased on Amazon and I encountered no problems under either Linux Zorin (standard drivers) or Windows 11 (Wifi-BT_1.1042.0.517 drivers).
Awesome. Yeah, depending on certain conditions, you might not run into issues. That’s the fun of race conditions being non-deterministic, and the different mix of network equipment and environmental conditions that can aggravate these bugs. Like, if your AP setup is an enterprise or mesh AP with Wi-Fi 7 and you can roam, or if your Wi-Fi 6E or Wi-Fi 7 AP has MLO support, it’s much easier to lose the race conditions in the driver and crash. But if you have an older single-Wi-Fi router, you don’t have fast-roam, and you don’t use or support 6 GHz on your AP (or only use 6 GHz and not multiple frequencies), always have a strong wifi connection, etc then your chances of hitting these 20-something bugs (of 3 classes) that I fixed are drastically lower.
For Windows, it won’t have the kernel driver that can crash your entire machine, as these fixes fix (actually, I can’t say that for sure since the MediaTek Windows driver is closed source, but some drivers don’t run in ring 0 with the kernel, and they are vetted differently and have to meet certain requirements to get signed by Windows, etc). Some issues are on the firmware side, but different OSes don’t use the same commands or interact with the hardware in exactly the same way, so one OS can exacerbate certain firmware bug behaviors more than others.
What’s your AP/Router? From what I seen it only affects those with Wi-Fi 6 or 7 capable APs. Those with relatively older hardware aren’t affected much.
I have just installed the dkms modules on my FW13 7040 with the MT7922/RZ616. I know your focus was primarily on the MT7925, but I saw you also had patches for the MT7921e driver (used by MT7922) and some libraries, so given that I have experienced some issues, I thought it would be good to give it a try.
The install went fine, but immediately on module load at boot, I see this NULL pointer dereference: 26-01-23-mt792x_lib.dmesg. As a result, no network interface. Are these patches expected to work with the MT7922?
Component
Version
OS
Artix Linux
Kernel
6.18.6
UEFI
3.18
Git commit
a00b48b
P.S.
The module version in install.sh does not match uninstall.sh, causing the uninstaller to fail. Also, the rmmod module unload was not successful for me in either script (module in use), requiring a reboot to actually switch.
The install went fine, but immediately on module load at boot, I see this NULL pointer dereference: 26-01-23-mt792x_lib.dmesg. As a result, no network interface. Are these patches expected to work with the MT7922?
The patches, yes, but the DKMS version is a little different because it’s been updated to support a wider range of kernels concurrently, so it’s actually based on a lot of changes in the newer bleeding-edge kernel. If you are using the DKMS package, it currently only builds the mt7925.ko and the shared mt792x-lib.ko library (and a few other shared libraries) that are used by both drivers, but it doesn’t rebuild mt7921e.ko by default, so your kernel will load the DKMS version of mt792x-lib.ko but use your kernel’s existing mt7921e.ko driver, and they won’t be stable together. That would lead to this crash, since the whole DKMS package is based on a newer kernel, so things are not ABI-stable.
I went ahead and made the DKMS package now build both mt7925.ko and mt7921e.ko for you. I can’t test mt7921e.ko too much here, but it will stop this particular crash. Otherwise, I would run the uninstall script. I only fixed a couple of small bugs for that chip and it’s much harder to run into those bugs than it is on the newer chip.
I also just fixed the uninstall script. It should remove all versions, new and old now.
I’m not sure when upstream will finish reviewing the patches I started last year, so I’m gearing up to maintain this DKMS solution for the long term and building AUR, deb, and RPM versions of the driver to make installation easier.
Nice. I’m currently on upstream-v2-patches (it was the only branch with the updated DKMS build when I installed), but I’ll plan to switch to the AUR package when you have that ready (unless there’s some reason not to).
I updated the original post so folks know what is going since it’s no longer relevant. I launched a new website with new AUR, deb, and RPM packages so it’s easier to get these fixes without the install script. I haven’t heavily tested those packages so any feedback would be awesome (in theory they just install the right dependencies and still install the dkms packages in the same way it does right now).
GOOD NEWS. Some of my patches are landing upstream in the wifi maintainers’ downstream repo, and Linus will usually take changes from this repo into its repo at regular intervals. I’m hoping my fixes hit mainline in a few weeks. Some folks also fixed some of the bugs I addressed in other ways in a couple of cases. About half of the changes I made are now upstream in some form. I have a few new fixes in the pipeline, too. One of my more controversial fixes isn’t going because it’s raising a lot of conversation, and we all agree it wasn’t in the right spot, but the best spot for me to fix in the DKMS version, but the bug is actually a few layers up that I can’t easily fix with a DKMS driver.
I’m working to update the DKMS version to backport a whole mess of fixes from others into that driver so you can enjoy them without just adopting a bleeding-edge kernel (since new features are mixed with bug fixes.
Thanks for making a debian version. I’ve got that installed, successfully stopped the kernel panics but wifi still very unstable - too unstable to run a speedtest.net, will be switching back to my guest network until those issues are fixed
This thread has been quiet for a while–has there been any upstream movement on patches or drivers? I hadn’t applied the patch as I’m on Bazzite and things were fine IME…well until last night.
Suddenly my FD wifi doesn’t work outside of 2.4gHz modes on my SSIDs, doesn’t even see my 5gHz SSID…and the most throughput I can get is 10megabit/second. It was truly bizzare as I was watching a YouTube stream–and mid-stream it just choked buffering. I gave it reboots, turned off wifi powersaving. I wonder if it is a bad driver update in the background, or if the wifi card went bad? All my other devices are completely fine it is just my Framework Desktop that has borked wifi. running on hardline for now until I figure out what to do
