* Re: mt7921e: repeated driver own failures cause hanging
2026-01-03 7:10 ` mt7921e: repeated driver own failures cause hanging Sean Wang
@ 2026-01-04 8:19 ` moosager90
2026-04-09 1:41 ` Vinicius
2026-07-27 16:27 ` moosager
2 siblings, 0 replies; 4+ messages in thread
From: moosager90 @ 2026-01-04 8:19 UTC (permalink / raw)
To: Sean Wang; +Cc: linux-wireless, moderated list:ARM/Mediatek SoC support
Hi Sean,
I'm resending this because I forgot to Cc the mailing lists.
On Sat, Jan 3, 2026 at 7:24 PM moosager90 <moosager90@gmail.com> wrote:
> Hi Sean,
>
> I have updated the firmware using the files you recommended (and I will wait
> for the issue to occur again), but I believe my distro's (Fedora 43) packages
> were already up to date, as the files already present on my system had the
> same hash as the newly downloaded ones; so the issue has been happening on
> the latest firmware (it was also happening on earlier ones, but I don't
> know since when).
>
> > Could you please share more details on how this issue can be
> > reproduced? For example, does it occur after suspend/resume, under
> > heavy traffic, or during normal runtime?
>
> There are no specific circumstances for it, it just happens during normal
> runtime: no heavy load is required to trigger it. I haven't ever seen the issue
> happen immediately after suspend/resume either; I don't believe that's related.
> I have a feeling that it has happened more often when connected to a
> public, password-less Wi-Fi network, though I'm not sure; it also
> happens any other network.
>
> > Also, please confirm which firmware version you are using.
>
> The dmesg output given by my distro's firmware files was:
> [ 16.313264] mt7921e 0000:62:00.0: enabling device (0000 -> 0002)
> [ 16.329376] mt7921e 0000:62:00.0: ASIC revision: 79220010
> [ 16.405931] mt7921e 0000:62:00.0: HW/SW Version: 0x8a108a10, Build Time: 20251118163143a
> [ 16.790050] mt7921e 0000:62:00.0: WM Firmware Version: ____000000, Build Time: 20251118163234
> which is identical to that given by the latest firmware files from git.
>
> More precisely, the firmware from my distro is that at [1]
> (mt7xxx-firmware-20251125-1.fc43.noarch.rpm is relevant), which I believe
> corresponds to branch [2] of linux-firmware, which is the latest one.
>
> > As a debugging step, could you also try disabling PCIe ASPM and check
> > whether the issue still occurs?
>
> I have now added pcie_aspm=off to my boot options; however, I had already done
> that in the past and the issue still happened. Here is an excerpt of the log
> from that time:
>
> kernel: Linux version 6.17.8-wifibuild+ ... (gcc (GCC) 15.2.1 20251022 (Red Hat 15.2.1-3), GNU ld version 2.45-1.fc43) #1 SMP > PREEMPT_DYNAMIC Fri Nov 14 12:24:21 CET 2025
> kernel: Command line: ... BOOT_IMAGE, root, ro, rootflags and rd.luks.uuid options ... quiet loglevel=3 udev.log-priority=3 > pcie_aspm=off
> ... messages ...
> kernel: mt7921e 0000:62:00.0: enabling device (0000 -> 0002)
> kernel: mt7921e 0000:62:00.0: ASIC revision: 79220010
> kernel: mt7921e 0000:62:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250523103150a
> kernel: mt7921e 0000:62:00.0: WM Firmware Version: ____000000, Build Time: 20250523103234
> ... messages ...
> ... repeated sequences of driver own failures ...
> kernel: mt7921e 0000:62:00.0: Message 00020003 (seq 6) timeout
> kernel: mt7921e 0000:62:00.0: Message 00020003 (seq 7) timeout
> kernel: mt7921e 0000:62:00.0: driver own failed
> kernel: mt7921e 0000:62:00.0: Timeout for driver own
> kernel: mt7921e 0000:62:00.0: driver own failed
> kernel: mt7921e 0000:62:00.0: Timeout for driver own
> kernel: mt7921e 0000:62:00.0: Message 00020003 (seq 8) timeout
> kernel: mt7921e 0000:62:00.0: driver own failed
>
> I had built the vanilla kernel myself at that time, hence the tag. That was
> before November 25, but I believe I might have been running the same firmware
> as today as it was provided by Fedora's testing packages at that time.
>
> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2865762
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?> h=20251125&id=4ee5122b3f58e4c07951746c4425e2f4f42e860f
>
> On Sat, Jan 3, 2026 at 8:10 AM Sean Wang <sean.wang@kernel.org> wrote:
> > Hi moosager90,
> >
> > Could you please share more details on how this issue can be
> > reproduced? For example, does it occur after suspend/resume, under
> > heavy traffic, or during normal runtime? Also, please confirm which
> > firmware version you are using.
> >
> > It would be helpful to test with the latest linux-firmware version:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/mediatek?> id=5cf85776762a544ad27c4447b61eaabb0d4716e7
> >
> > As a debugging step, could you also try disabling PCIe ASPM and check
> > whether the issue still occurs?
> >
> > Sean
> >
> > On Fri, Jan 2, 2026 at 4:35 AM moosager90 <moosager90@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > There is an issue with mt7921e which causes repeated failures in chip resets,
> > > bringing the network down and causing hanging on every command or action on the
> > > system; the only workaround is to reboot. This is what the kernel output looks
> > > like at those times:
> > >
> > > mt7921e 0000:62:00.0: driver own failed
> > > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > > kernel: mt7921e 0000:62:00.0: driver own failed
> > > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > > kernel: mt7921e 0000:62:00.0: driver own failed
> > > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > > kernel: mt7921e 0000:62:00.0: driver own failed
> > > kernel: mt7921e 0000:62:00.0: chip reset failed
> > > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > > kernel: Console: switching to colour frame buffer device 360x112
> > > kernel: fbcon: Taking over console
> > > kernel: mt7921e 0000:62:00.0: Message 00020001 (seq 1) timeout
> > >
> > > I have observed the issue on many untainted kernels, and I have had it happen on
> > > vanilla kernels not provided by my distro as well.
> > >
> > > Mine and some other people's reports are available at [1]. More logs of the
> > > issue on my system are in the attachments of my original report on the Red Hat
> > > Bugzilla [2].
> > >
> > > In the past, the issue was reported at [3], which resulted in a patch [4] that
> > > only keeps the system running instead of panicking. This means the driver still
> > > causes system hangs.
> > >
> > > I still don't know the root cause of the issue and I would like to get to the
> > > bottom of this; any help or guidance is appreciated. Crucially, I have not found
> > > a way to reproduce the issue at will.
> > >
> > > Best regards.
> > >
> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=220353
> > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2411854
> > > [3] https://lore.kernel.org/linux-wireless/VE1PR04MB64945C660A81D38F290E4A4BE59F9@VE1PR04MB6494.eurprd04.prod.outlook.com/> T/#u
> > > [4] https://patchwork.kernel.org/project/linux-wireless/patch/> 727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com/
> > >
> > >
> > >
> > >
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mt7921e: repeated driver own failures cause hanging
2026-01-03 7:10 ` mt7921e: repeated driver own failures cause hanging Sean Wang
2026-01-04 8:19 ` moosager90
@ 2026-04-09 1:41 ` Vinicius
2026-07-27 16:27 ` moosager
2 siblings, 0 replies; 4+ messages in thread
From: Vinicius @ 2026-04-09 1:41 UTC (permalink / raw)
To: Sean Wang, moosager90
Cc: linux-wireless, moderated list:ARM/Mediatek SoC support
Hi Sean,
moosager90 recommended me to reply to this thread when we were talking
about a bug reported at
https://bugzilla.kernel.org/show_bug.cgi?id=220353
This bug reported in bugzilla is related to mt7921e raising several
"driver own failed" messages in dmesg. But it seems this same bug is
also affecting me through **mt7925e** driver.
Before posting below a log from my dmesg, which also shows several
"driver own failed" messages, I would like to say in advance that yes,
the bug was occurring every time my computer suspended. I first tried
to disable the auto-suspend feature of my linux distro and the bug
stopped happening too often, but was still happening sometimes. In
~March 28th the bug was being triggered too much (even without the
computer being suspended), freezing my computer and requiring a reboot.
So I tried adding `options mt7925e disable_aspm=1` to
`/etc/modprobe.d/mt7925e.conf`. I think this is what you suggested when
you said "could you also try disabling PCIe ASPM...".
**Since I added this line to disable ASPM, I have not experienced more
freezes. It seems this line really fixed the issue.**
Below you can find all the information about the kernel version I'm
using, as well as the driver version, firmware version and logs from
dmesg (a copy-paste from my message at bugzilla on March 25th):
```
# uname -a
Linux arch 6.19.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 19 Mar 2026
16:33:17 +0000 x86_64 GNU/Linux
---
# journalctl -k -g mt7925e -b -1
mar 25 09:00:09 arch kernel: mt7925e 0000:01:00.0: enabling device
(0000 -> 0002)
mar 25 09:00:09 arch kernel: mt7925e 0000:01:00.0: ASIC revision:
79250000
mar 25 09:00:09 arch kernel: mt7925e 0000:01:00.0: HW/SW Version:
0x8a108a10, Build Time: 20260106153007a
mar 25 09:00:09 arch kernel: mt7925e 0000:01:00.0: WM Firmware Version:
____000000, Build Time: 20260106153120
mar 25 09:00:10 arch kernel: mt7925e 0000:01:00.0 wlp1s0: renamed from
wlan0
mar 25 10:25:16 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:25:17 arch kernel: mt7925e 0000:01:00.0: driver own failed
...
mar 25 10:25:42 arch kernel: mt7925e 0000:01:00.0: chip reset failed
mar 25 10:25:45 arch kernel: mt7925e 0000:01:00.0: Message 00020001
(seq 9) timeout
mar 25 10:25:48 arch kernel: mt7925e 0000:01:00.0: Message 00020004
(seq 10) timeout
mar 25 10:25:51 arch kernel: mt7925e 0000:01:00.0: Message 00020002
(seq 11) timeout
mar 25 10:25:54 arch kernel: mt7925e 0000:01:00.0: Message 00020001
(seq 12) timeout
mar 25 10:25:57 arch kernel: mt7925e 0000:01:00.0: Message 00020004
(seq 13) timeout
mar 25 10:25:58 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:26:00 arch kernel: mt7925e 0000:01:00.0: Message 00020027
(seq 14) timeout
mar 25 10:26:04 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:26:06 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:26:07 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:26:08 arch kernel: mt7925e 0000:01:00.0: driver own failed
mar 25 10:26:14 arch kernel: mt7925e 0000:01:00.0: Message 00020003
(seq 15) timeout
---
# modinfo mt7925e
filename: /lib/modules/6.19.9-arch1-
1/kernel/drivers/net/wireless/mediatek/mt76/mt7925/mt7925e.ko.zst
license: Dual BSD/GPL
description: MediaTek MT7925E (PCIe) wireless driver
author: Lorenzo Bianconi <lorenzo@kernel.org>
author: Deren Wu <deren.wu@mediatek.com>
firmware: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
srcversion: CB386A1D0C64CC7F4C723D9
alias: pci:v000014C3d00000717sv*sd*bc*sc*i*
alias: pci:v000014C3d00007925sv*sd*bc*sc*i*
depends: mt792x-lib,mt76-connac-lib,mt76,mt7925-common,rfkill
intree: Y
name: mt7925e
retpoline: Y
vermagic: 6.19.9-arch1-1 SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:
6F:56:40:C8:60:B3:9B:AD:DF:E1:84:24:BC:D4:A9:07:90:4E:7B:C6
sig_hashalgo: sha512
signature:
30:64:02:30:54:34:C4:0C:8E:A8:D6:EB:38:02:71:55:A3:09:CA:39:
28:2E:F3:8C:2C:38:AB:26:89:8A:B7:3E:66:77:40:26:C7:D5:
13:12:
CA:39:F4:99:1A:EC:3B:0C:D4:8D:D7:C0:02:30:62:78:5D:DC:
90:B7:
57:5E:CE:F5:64:99:EF:AC:B9:3B:B7:00:3E:EE:BA:B7:81:C2:
8F:2C:
DF:B2:F4:64:3C:76:54:24:0B:70:72:56:80:7E:28:5A:56:71:
45:D6:
A7:57
parm: disable_aspm:disable PCI ASPM support (bool)
```
Best regards.
On Sat, 2026-01-03 at 01:10 -0600, Sean Wang wrote:
> Hi moosager90,
>
> Could you please share more details on how this issue can be
> reproduced? For example, does it occur after suspend/resume, under
> heavy traffic, or during normal runtime? Also, please confirm which
> firmware version you are using.
>
> It would be helpful to test with the latest linux-firmware version:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/mediatek?id=5cf85776762a544ad27c4447b61eaabb0d4716e7
>
> As a debugging step, could you also try disabling PCIe ASPM and check
> whether the issue still occurs?
>
> Sean
>
> On Fri, Jan 2, 2026 at 4:35 AM moosager90 <moosager90@gmail.com>
> wrote:
> >
> > Hello,
> >
> > There is an issue with mt7921e which causes repeated failures in
> > chip resets,
> > bringing the network down and causing hanging on every command or
> > action on the
> > system; the only workaround is to reboot. This is what the kernel
> > output looks
> > like at those times:
> >
> > mt7921e 0000:62:00.0: driver own failed
> > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > kernel: mt7921e 0000:62:00.0: driver own failed
> > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > kernel: mt7921e 0000:62:00.0: driver own failed
> > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > kernel: mt7921e 0000:62:00.0: driver own failed
> > kernel: mt7921e 0000:62:00.0: chip reset failed
> > kernel: mt7921e 0000:62:00.0: Timeout for driver own
> > kernel: Console: switching to colour frame buffer device 360x112
> > kernel: fbcon: Taking over console
> > kernel: mt7921e 0000:62:00.0: Message 00020001 (seq 1) timeout
> >
> > I have observed the issue on many untainted kernels, and I have had
> > it happen on
> > vanilla kernels not provided by my distro as well.
> >
> > Mine and some other people's reports are available at [1]. More
> > logs of the
> > issue on my system are in the attachments of my original report on
> > the Red Hat
> > Bugzilla [2].
> >
> > In the past, the issue was reported at [3], which resulted in a
> > patch [4] that
> > only keeps the system running instead of panicking. This means the
> > driver still
> > causes system hangs.
> >
> > I still don't know the root cause of the issue and I would like to
> > get to the
> > bottom of this; any help or guidance is appreciated. Crucially, I
> > have not found
> > a way to reproduce the issue at will.
> >
> > Best regards.
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=220353
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2411854
> > [3]
> > https://lore.kernel.org/linux-wireless/VE1PR04MB64945C660A81D38F290E4A4BE59F9@VE1PR04MB6494.eurprd04.prod.outlook.com/T/#u
> > [4]
> > https://patchwork.kernel.org/project/linux-wireless/patch/727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com/
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mt7921e: repeated driver own failures cause hanging
2026-01-03 7:10 ` mt7921e: repeated driver own failures cause hanging Sean Wang
2026-01-04 8:19 ` moosager90
2026-04-09 1:41 ` Vinicius
@ 2026-07-27 16:27 ` moosager
2 siblings, 0 replies; 4+ messages in thread
From: moosager @ 2026-07-27 16:27 UTC (permalink / raw)
To: Sean Wang; +Cc: linux-wireless, moderated list:ARM/Mediatek SoC support
Hello,
On Sat, Jan 3, 2026 at 8:10 AM Sean Wang <sean.wang@kernel.org> wrote:
> Hi moosager90,
>
> Could you please share more details on how this issue can be
> reproduced?
I have found a (somewhat hacky) way to reliably reproduce the issue.
Just run this script for 3-5 seconds:
#!/bin/sh
echo 0x7c060010 > /sys/kernel/debug/ieee80211/phy0/mt76/regidx
while true; do echo 0xffffffff > /sys/kernel/debug/ieee80211/phy0/mt76/regval ; done
Running this script results in the same "driver own failed" messages and system
slowdowns observed when the issue naturally occurs.
I have investigated the bug a little and found how it manifests in the driver
code:
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 essence, the above script recreates those conditions by writing 0xffffffff
to the MT_CONN_ON_LPCTL register (at address 0x7c060010).
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.
This issue still happens and is still reproducible on my build of the vanilla
7.2.0-rc4 kernel, as it has been for every past kernel version.
This is my best attempt at investigating it, but i believe it is ultimately
down to the firmware rather than the driver.
> Also, please confirm which firmware version you are using.
Here is the 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
> As a debugging step, could you also try disabling PCIe ASPM and check
> whether the issue still occurs?
The issue happens whether ASPM is on or off.
^ permalink raw reply [flat|nested] 4+ messages in thread