mt7921e: failure to reset causes network drop

mt7921e: failure to reset causes network drop

[moosager]

Hello,
there is an issue with the mt7291e that causes the network to drop at random, 
with dmesg outputting repeatedly:
kernel: mt7921e 0000:62:00.0: Timeout for driver own
kernel: mt7921e 0000:62:00.0: driver own failed

Other effects are the system becoming generally unresponsive, kernel panics 
(reporting "Fatal exception in interrupt"), and the system instantly rebooting. 
It also has a tendency to happen again on every subsequent reboot.
More reports of users' experiences are available at [1].

This script lets you reproduce the issue:
#!/bin/sh
echo 0x7c060010 > /sys/kernel/debug/ieee80211/phy0/mt76/regidx
while true; do echo 0xffffffff > /sys/kernel/debug/ieee80211/phy0/mt76/regval ; done

I had previously investigated the code and have some potential insight: during 
normal usage, the function __mt792xe_mcu_drv_pmctrl writes to a register 
like this:
mt76_wr(dev, MT_CONN_ON_LPCTL, PCIE_LPCR_HOST_CLR_OWN);

and it expects to find 0x00000004 (which is PCIE_LPCR_HOST_OWN_SYNC). Instead, 
when the issue happens, it finds 0xffffffff, which does not change even after 
the driver attempts to write to it.

In addition, the failure of __mt792xe_mcu_drv_pmctrl returns -5 as an error 
code; this is not checked by the caller, mt7921e_mac_reset, which calls 
mt792xe_mcu_drv_pmctrl without checking its return value.
 
I have also found some potentially helpful patches at [2]; however, applying 
them did not fix it, and my best attempts at adapting the proposed code paths to 
be triggered in mt7921e_mac_reset have not fixed it either.

Here is my firmware version reported in dmesg:

[   15.848101] mt7921e 0000:62:00.0: enabling device (0000 -> 0002)
[   15.849369] mt7921e 0000:62:00.0: disabling ASPM  L1
[   15.865381] mt7921e 0000:62:00.0: ASIC revision: 79220010
[   15.958433] mt7921e 0000:62:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260605203307a
[   16.352504] mt7921e 0000:62:00.0: WM Firmware Version: ____000000, Build Time: 20260605203411

It has also been happening at least since the firmware with HW/SW build time 
20251118163143a and WM firmware build time 20251118163234, which is when I got 
my laptop with this Wi-Fi chip.

Note: the issue happens whether ASPM is on or off.
The issue happens on my build of the vanilla 7.2.0-rc4 kernel, as it has 
been happening on every past kernel version.

I would like some guidance as to how I could debug the issue further, though 
ultimately the problem is likely in the firmware. It would be very helpful to 
have this fixed, as it currently makes my laptop almost unusable, and I know I'm 
not the only user having this issue.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=220353
[2] https://lore.kernel.org/linux-mediatek/20260506070458.3096180-1-jb.tsai@mediatek.com/

Re: mt7921e: failure to reset causes network drop

[Devin Wittmayer]

moosager,

Sorry this sat so long. You were right about the unchecked return. There
is a patch for it that the maintainer has taken, though it has not reached
a release yet:

    14739102  mt7921: check drv_pmctrl return in the PCIe reset path
    14739848  mt7925, same

It sits downstream of your bad read though, so it will not stop the
register going wrong in the first place.

On debugging further, I had the same ownership handshake fail on a mini
PC here. What that ruled out, so you can skip them: in-tree against
out-of-tree builds, a PCI bus reset, remove and rescan, and a cold boot.
The Bluetooth half of the same chip kept working throughout, so the
silicon was alive and only the WiFi side was stuck.

Devin

Re: mt7921e: failure to reset causes network drop

[moosager]

Hi Devin,

> On debugging further, I had the same ownership handshake fail on a mini PC 
> here. What that ruled out, so you can skip them: in-tree against out-of-tree 
> builds, a PCI bus reset, remove and rescan, and a cold boot. The Bluetooth 
> half of the same chip kept working throughout, so the silicon was alive and 
> only the WiFi side was stuck.

I can confirm these are the things I've had to rule out with my testing as well.
I can also attest to the fact that the Bluetooth half of the chip works 
regardless of the Wi-Fi's state (I should've mentioned that earlier): I've used 
my laptop for a while with mt7921e unloaded, all the while Bluetooth was working 
the whole time.

> There is a patch for it that the maintainer has taken

Good, though I don't see which tree it has been merged in, I'm sure I'll see it 
soon in a future release.

> It sits downstream of your bad read though, so it will not stop the
> register going wrong in the first place.

True, I will stress that the root cause has not been found yet and this chip is 
still unusable for me (and others).

Sorry for the late reply, I'll test the output of lspci as well when I get the 
chance to debug this further.

Re: mt7921e: failure to reset causes network drop

[Devin Wittmayer]

moosager,

Thanks for confirming the ruling-out list, and the Bluetooth detail is
worth having on the thread.

On which tree. Patchwork says accepted, which means a maintainer took it
and says nothing about mainline. That is why you could not find it.

	openwrt/mt76   8e856ad93d3a   mt7921, applied 27 August
	               4f2aa9910e0c   mt7925, applied 27 August
	mainline       neither, checked today

Mainline still ignores the return in both of those resets, and I would
not put a date on when that changes.

Your Tested-by went on the mt7921 one.

Devin

On Sat, 12 Sep 2026, moosager wrote:

> Hi Devin,
>
> > On debugging further, I had the same ownership handshake fail on a mini PC
> > here. What that ruled out, so you can skip them: in-tree against out-of-tree
> > builds, a PCI bus reset, remove and rescan, and a cold boot. The Bluetooth
> > half of the same chip kept working throughout, so the silicon was alive and
> > only the WiFi side was stuck.
>
> I can confirm these are the things I've had to rule out with my testing as well.
> I can also attest to the fact that the Bluetooth half of the chip works
> regardless of the Wi-Fi's state (I should've mentioned that earlier): I've used
> my laptop for a while with mt7921e unloaded, all the while Bluetooth was working
> the whole time.
>
> > There is a patch for it that the maintainer has taken
>
> Good, though I don't see which tree it has been merged in, I'm sure I'll see it
> soon in a future release.
>
> > It sits downstream of your bad read though, so it will not stop the
> > register going wrong in the first place.
>
> True, I will stress that the root cause has not been found yet and this chip is
> still unusable for me (and others).
>
> Sorry for the late reply, I'll test the output of lspci as well when I get the
> chance to debug this further.