Re: [BUG] mt7921e: Intermittent connection failure

[silverducks <silverducks@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3853 bytes --]

Greetings!

On 17/04/2026 00:59, Sean Wang wrote:
 > I tried to reproduce the issue with your script on an mt7921u, but I
 > could not reproduce the timeout on my side.
 > <...>
 > If this were a generic race in the common MCU command layer, I would
 > expect it to reproduce on mt7921u as well.
It sounds like you are referring to the original bug as timeout here.
I may not have been clear about this, let me restate it more
precisely. My apologies if this is redundant.
--------------
mt7921e 0000:02:00.0: Message 0004001b (seq 9) timeout
--------------
This timeout error appears with aforementioned patch applied.
It seems to "replace" the bug during NM-autoconnect-reliant runs -
it's occurrence rate is the same and the original bug no longer
triggers. It causes the driver to reset:
--------------
[  124.601521] mt7921e 0000:02:00.0: Message 0004001b (seq 5) timeout
[  124.689461] mt7921e 0000:02:00.0: HW/SW Version: 0x8a108a10, Build 
Time: 20250625153620a

[  124.726504] mt7921e 0000:02:00.0: WM Firmware Version: ____010000, 
Build Time: 20250625153703
--------------
On the other hand, the original bug makes the device unresponsive,
but does not cause an error message or cause the driver to reset [1].

If I use nmcli to connect instead (as in previous revision of the
script) with the patch applied, this timeout starts to appear
significantly more frequently. It's not impossible that it's a
statistical outlier, but I did run this a number of times.

Without the patch, using nmcli to connect mostly gets rid of the bug:
occurrence rate drops considerably, though not to zero.
I think it simply allows less time for NM to trigger the bug.

 > If this were a generic race in the common MCU command layer, I would
 > expect it to reproduce on mt7921u as well.
Perhaps it could still exist in the common layer, if the USB version
is not triggering it due to slower bus speed or latency, or
some other difference?
Though, I'm not saying that aforementioned patch fixes the core issue.
More likely it only prevents the trigger from occurring.

 > Also, could you record and save the "iw event" log when you run the
 > test? That would help show what userspace-triggered
 > activities are happening. we can mimic the same sequence using wpa_cli
Of course. Attaching logs for module reload and reconnecting cases.

Thank you for your time.

[1]
<cut>
[  208.992595] wlp2s0: deauthenticating from 34:60:f9:99:08:38 by local 
choice (Reason: 3=DEAUTH_LEAVING)
[  209.611215] mt7921e 0000:02:00.0: ASIC revision: 79610010
[  209.697087] mt7921e 0000:02:00.0: HW/SW Version: 0x8a108a10, Build 
Time: 20250625153620a

[  209.734750] mt7921e 0000:02:00.0: WM Firmware Version: ____010000, 
Build Time: 20250625153703
[  210.579495] mt7921e 0000:02:00.0 wlp2s0: renamed from wlan0
[  215.603597] wlp2s0: authenticate with 34:60:f9:99:08:38 (local 
address=14:5a:fc:77:82:1f)
[  215.718389] wlp2s0: send auth to 34:60:f9:99:08:38 (try 1/3)
[  218.790084] wlp2s0: send auth to 34:60:f9:99:08:38 (try 2/3)
[  220.723047] wlp2s0: aborting authentication with 34:60:f9:99:08:38 by 
local choice (Reason: 3=DEAUTH_LEAVING)
[  234.992512] wlp2s0: authenticate with 34:60:f9:99:08:38 (local 
address=14:5a:fc:77:82:1f)
[  236.005909] wlp2s0: send auth to 34:60:f9:99:08:38 (try 1/3)
[  239.078085] wlp2s0: send auth to 34:60:f9:99:08:38 (try 2/3)
[  240.695078] wlp2s0: aborting authentication with 34:60:f9:99:08:38 by 
local choice (Reason: 3=DEAUTH_LEAVING)
[  254.926181] wlp2s0: authenticate with 34:60:f9:99:08:38 (local 
address=14:5a:fc:77:82:1f)
[  255.973995] wlp2s0: send auth to 34:60:f9:99:08:38 (try 1/3)
[  257.061953] wlp2s0: send auth to 34:60:f9:99:08:38 (try 2/3)
[  258.149899] wlp2s0: send auth to 34:60:f9:99:08:38 (try 3/3)
[  258.173202] wlp2s0: authentication with 34:60:f9:99:08:38 timed out
<end of log>


[-- Attachment #2: attachments.tar.gz --]
[-- Type: application/gzip, Size: 169901 bytes --]