From: moosager <moosager90@gmail.com>
To: Sean Wang <sean.wang@kernel.org>
Cc: linux-wireless@vger.kernel.org,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>
Subject: Re: mt7921e: repeated driver own failures cause hanging
Date: Mon, 27 Jul 2026 18:27:53 +0200 [thread overview]
Message-ID: <amd7c3Xk6NhBQr9x@fedora.fritz.box> (raw)
In-Reply-To: <CAGp9Lzp8NjVwkn2atNqT9x9-QTkWMLxK+Ntkb=3Z1fWcM6N=7A@mail.gmail.com>
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.
prev parent reply other threads:[~2026-07-27 16:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4870974.vXUDI8C0e8@fedora.fritz.box>
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amd7c3Xk6NhBQr9x@fedora.fritz.box \
--to=moosager90@gmail.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=sean.wang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox