mt7921e: repeated driver own failures cause hanging

Sun Jan 4 00:19:39 PST 2026

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 at 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 at 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 at 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 at mediatek.com/
> > >
> > >
> > >
> > >
> >