Ubuntu Version
Ubuntu 26.04 LTS
Desktop Environment (if applicable)
GNOME
Problem Description
Intermittent WIFI on Mediatek mt7921 chip
Relevant System Information
The MediaTek MT7922 Wi-Fi adapter (mt7921e) on Ubuntu 26.04 with kernel 7.0.0-30-generic fails to initialise correctly on boot and after suspend/resume. The card associates at the link layer and receives an IP address, but no packets are transmitted. The connection is unstable, slow, and drops intermittently. A manual driver reload temporarily restores connectivity.
Affected configuration
· OS: Ubuntu 26.04 LTS
· Kernel: 7.0.0-30-generic (also reported from 7.0.0-27 onward)
· Hardware: ASUS Zenbook UM3402Y, BIOS UM3402YAR.302
· Wi-Fi chip: MediaTek MT7922 (PCI ID 14c3:0616) — also branded as AMD RZ616
· Driver: mt7921e
Error Messages / Logs
To check whether you have the affected chip:
lspci -nnk | grep -iA3 mediatek
What I’ve Tried
Symptoms
· Wi-Fi is slow and unstable, with intermittent drops
· The connection shows as “connected”, but pages do not load
· ping to the local gateway fails despite an assigned IP address:
ip addr show # shows a valid inet address
ping -c 3 192.168.178.1 # fails
· After a reboot or suspend/resume, Wi-Fi may refuse to connect entirely
Quick test: is it the driver?
sudo rmmod mt7921e && sudo modprobe mt7921e
If your connection immediately returns and works properly, you have confirmed a driver initialisation failure — not your router, not your configuration. That is the signature of this bug.
Likely cause
The behaviour matches a firmware-loading deadlock pattern. If a firmware load is interrupted after the driver acquires the hardware “patch semaphore” but before the device releases it, every subsequent load attempt fails. The driver cannot recover without a full module reload.
Related upstream work also covers forcing the device back to a default state during probe (relevant when UEFI pre-boot Wi-Fi has left the chip in a non-default state) and avoiding PCIe Function Level Reset (FLR) on this device, which is advertised but non-functional and can leave the card permanently unusable after a reset event.
These fixes exist upstream but do not appear to be present in Ubuntu’s 7.0.0-30 kernel.
Workaround
Install the community-maintained DKMS driver from morrownr/mt76. It tracks upstream mt76 more closely than Ubuntu’s in-tree driver and blacklists the in-tree mt7921e / mt7921_common modules on install.
- Install prerequisites:
sudo apt update
sudo apt install -y linux-headers-$(uname -r) build-essential dkms git
- Clone and install:
mkdir -p ~/src && cd ~/src
git clone https://github.com/morrownr/mt76.git
cd mt76
sudo sh install-driver.sh
- Reboot:
sudo reboot
If Secure Boot is enabled, the installer will prompt for a MOK password. Note it — you will need to enter it at the blue MOK Manager screen on the next boot (Enroll MOK → Continue → Yes → password → Reboot).
- Verify only the DKMS modules are loaded:
lsmod | grep mt7921
Expected:
mt7921e_git
mt7921_common_git
If mt7921e or mt7921_common (without the _git suffix) also appear, check the blacklist created by the installer:
cat /etc/modprobe.d/mt76_git.conf
It should contain:
blacklist mt7921e
blacklist mt7921_common
Optional: prevent a DKMS compression papercut
On some Ubuntu systems, DKMS installs modules compressed as .ko.zst, which can cause the boot process to load the in-tree driver despite the blacklist. This did not appear to affect the fix here, but it is worth guarding against on future kernel updates:
sudo mkdir -p /etc/dkms/framework.conf.d
echo "compress_modules=no" | sudo tee /etc/dkms/framework.conf.d/compress.conf
If a compressed module does appear after a kernel update, decompress and rebuild:
ls -l /lib/modules/$(uname -r)/updates/dkms/ | grep mt7921
sudo unzstd --rm /lib/modules/$(uname -r)/updates/dkms/mt7921e_git.ko.zst
sudo depmod -a
sudo update-initramfs -u
sudo reboot
Outcome
With the DKMS driver installed, Wi-Fi reconnects automatically after both reboot and suspend/resume. No manual intervention is required. DKMS rebuilds the driver for each new kernel, so the workaround persists across updates.
To confirm after a kernel upgrade:
dkms status
lsmod | grep mt7921
Things that did not fix it
For anyone considering the same path:
· Disabling Wi-Fi power saving in NetworkManager (already configured before troubleshooting began)
· Disabling ASPM via the mt7921e module parameter — the parameter did not take effect (disable_aspm returned N)
· Adding pcie_aspm=off to the kernel command line — this caused total loss of connectivity and had to be reverted
· Disabling CLC
· Automating a driver reload via a systemd service — it ran too late in the boot sequence to be effective and was removed
Reverting
To return to the in-tree driver:
cd ~/src/mt76
sudo sh uninstall-driver.sh
sudo rm -f /etc/modprobe.d/mt76_git.conf
sudo update-initramfs -u
sudo reboot
Request
If a maintainer is reading: could the upstream mt792x firmware reload and probe fixes be backported to the Ubuntu 7.0.0-30 (and later) kernel? This affects any laptop shipping the MT7922 / AMD RZ616, which is a broad set of recent AMD-based machines. The in-tree driver is currently unusable on this hardware without an out-of-tree replacement.
If anyone can identify the corresponding Launchpad bug or the specific upstream commit series, please reply here so it can be tracked.
References
· morrownr/mt76 DKMS driver
· Launchpad — linux source package
· linux-wireless mailing list archive — search for mt792x firmware reload
A note on this post
This is a user-written summary based on a single confirmed case. The diagnosis matches known upstream patch discussions, but I have not included specific bug numbers or patch attributions because I could not verify them directly. If you find the corresponding Launchpad bug or LKML thread, please add it in a reply — it will help others and get this fixed in the kernel itself.