You are not logged in.

Pages: 1

#1 2025-09-18 17:05:46

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

Hi all,

I’m hitting recurrent kernel panics on an ASUS TUF Gaming A17 FA706IC. Initially the crashes looked Wi‑Fi-specific (mt76/mt7921e DMA crash during a MAC reset), but I have since reproduced a panic after suspend/resume while using Ethernet only (Wi‑Fi idle), so this may be a broader power-management/suspend regression on my platform.

Hardware
- Laptop: ASUS TUF Gaming A17 FA706IC
- Wi‑Fi: MEDIATEK MT7921 802.11ax PCIe [14c3:7961] (AzureWave [1a3b:4680]) — driver: mt7921e
- Bluetooth: IMC Networks Wireless_Device (MediaTek), typically active
- Ethernet: Realtek RTL8111/8168 (r8169)
- Graphics: AMD Renoir iGPU (amdgpu), NVIDIA dGPU present (nvidia modules)
- Storage: NVMe Micron/Crucial P2/P3 and Samsung 980 (both DRAM-less)
- BIOS: FA706IC.302 (2022-12-28)

OS / kernel / firmware
- Arch Linux
- Boot loader: systemd-boot 257.7-1-arch
- Kernels tested:
    - linux 6.16.7.arch1-1 (current)
    - linux-lts 6.12.47-1 (also affected, frequency differs)
- Firmware: linux-firmware 20250808-1
- Networking stack: systemd-networkd (no NetworkManager); iwd 3.9-1 installed but I’m using systemd-networkd for networking

Kernel cmdline (excerpt)

initrd=\amd-ucode.img initrd=\initramfs-linux.img cryptdevice=PARTUUID=...:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs splash quiet mt7921e.disable_aspm=1

Primary symptom A: panic in mt76 DMA path during MAC reset

Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
RIP: mt76_dma_add_buf.isra.0+0x88/0x1f0 [mt76]
Call trace: mt76_dma_tx_queue_skb_raw -> mt76_mcu_skb_send_and_get_msg -> mt76_connac_mcu_uni_add_dev -> mt7921_vif_connect_iter -> mt7921_mac_reset_work
Kernel panic - not syncing: Fatal exception in interrupt

- Tainted due to NVIDIA OOT modules, but the oops points squarely at mt76/mt7921 during a reset after AP disconnect.
- CR2 address consistent with invalid pointer in DMA path.

Primary symptom B: panic after suspend/resume while on Ethernet only
- Later crash occurred after the system went to sleep and resumed, with Ethernet active and Wi‑Fi idle. This suggests a platform suspend/resume interaction (PM, PCIe ASPM, NVMe, GPU, or r8169), not only mt76.

What I observe in logs

mt7921e 0000:03:00.0: ASIC revision: 79610010
mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250625153620a
mt7921e 0000:03:00.0: WM Firmware Version: ____010000, Build Time: 20250625153703

- Association flows on 5 GHz, ch 36, 80 MHz, then later deauth/reconnects.
- When I tried to reload the module with debug, kernel reports:

mt7921e: unknown parameter 'debug' ignored

- Bluetooth is active; coexistence could be a factor, but the Ethernet-only suspend crash points broader.
What I’ve tried
- Kernels:
    - linux 6.16.7: reproducible mt76 panic in MAC reset
    - linux-lts 6.12.47: also unstable at times (less frequent)
- Firmware:
    - Up to date: linux-firmware 20250808-1 (MT7961 blobs present/used)
- PCIe/Power:

mt7921e.disable_aspm=1

(active and confirmed in /sys/module/mt7921e/parameters)
    - sysfs power/control for Wi‑Fi is “on”
- Networking:
    - Using systemd-networkd; iwd 3.9-1 is installed
- Fallback:
    - Switched to Ethernet; still hit a panic after suspend/resume

Collected diagnostics
- lspci shows MT7921e at 0000:03:00.0 (14c3:7961), driver mt7921e
- rfkill shows no blocks
- iw reports normal caps; operating on 5 GHz 80 MHz
- dmesg/journal slices show the mt76 init, associations, and the earlier panic trace (mt76_dma_add_buf)
- Artifacts: I have a tarball from a collection script with:
    - System/kernels/firmware versions and module params
    - dmesg and journal slices
    - The panic backtrace

Questions and requests for guidance
mt76/mt7921 regression
- Is there a known mt76/mt7921 regression around linux 6.16 and these newer WM firmware builds leading to DMA ring issues on reset?
- Are mitigations like wed_enable=0 or reducing coalescing supported/appropriate on Arch’s mt76?
    - e.g.,

options mt7921e wed_enable=0

    - e.g.,

options mt76 txrx_coalesce=0

Suspend/resume instability (Ethernet-only case)
- On Renoir + r8169 + DRAM-less NVMe combo, are there recommended kernel params to try for suspend?

mem_sleep_default=deep

vs 

mem_sleep_default=s2idle
nvme_core.default_ps_max=1

nvme.noacpi=1
pcie_aspm=off

(test only)
    - r8169 runtime PM off:

echo on | sudo tee /sys/bus/pci/devices/0000:02:00.0/power/control
amdgpu.runpm=0

(or other amdgpu PM toggles)
- Any known suspend issues on 6.16.7 for this platform?

Debugging tips
- Best way to capture more detail on the suspend crash? pstore/EFI pstore suggestions welcome.
- For mt76, what debug flags are supported with mt7921e in Arch’s build? The module rejected:

modprobe mt7921e debug=0x1ff
-> mt7921e: unknown parameter 'debug' ignored

What I can test
- Blacklist mt7921e and loop suspend/resume to confirm Wi‑Fi independence of the suspend crash:

echo "blacklist mt7921e" | sudo tee /etc/modprobe.d/blacklist-mt7921e.conf

- Switch mem_sleep_default between s2idle and deep
- Try 

nvme_core.default_ps_max=1

and 

nvme.noacpi=1

- Try r8169 

power/control=on

and/or ASPM off
- Test linux-zen
- Temporarily disable Bluetooth to check coexistence

System details
- Hostname: cursedpc
- Kernel: 6.16.7-arch1-1 (PREEMPT_DYNAMIC)
- Boot cmdline includes: 

mt7921e.disable_aspm=1

- Firmware: linux-firmware 20250808-1
- BIOS: FA706IC.302 (2022-12-28)
- Networking: systemd-networkd; iwd installed

Most recent panic report

https://hastebin.skyra.pw/iyimewedok.prolog

Logs and artifacts
I can attach the tarball with:

mt7921_report_YYYYmmdd_HHMMSS.txt

- dmesg/journal slices
- prior panic backtrace with full call trace

Any pointers to related bug reports, patches to try, or recommended module/kernel parameters would be greatly appreciated. I’m happy to test and report back.

Thanks!


[EDIT 1]
Made the changes for easier reading with code tags.

Last edited by thecursedapple (2025-09-18 22:01:32)

Offline

#2 2025-09-18 18:50:08

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 24,923

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

Moving Kernel & Hardware issues, also please wrap outputs in  [code][/code] tags in the future.

Offline

#3 2025-09-18 19:36:33

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

I have since reproduced a panic after suspend/resume while using Ethernet only (Wi‑Fi idle)

rfkill the wifi, unload mt7921 and mt76 and reproduce the crash, ideally post the complete system journal of that run - can you still reboot using the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) or do you escape via https://wiki.archlinux.org/title/Kdump ?

There's

[63058.501882] wlan2: Driver requested disconnection from AP 70:df:f7:d0:c5:be

what are wlan0 and wlan1?
Maybe generally post your complete system journal for the boot: 

sudo journalctl -b | curl -F 'file=@-' 0x0.st

for an oversight of the situation.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#4 2025-09-18 21:48:17

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

Thanks for the reply!

- I hard‑blocked Wi‑Fi and attempted to unload the wireless stack. Some modules were initially “in use”, so I stopped network services, brought down/deleted wlan ifaces, and retried. I then did a clean reboot with a temporary blacklist to ensure the wireless stack stayed out.
- Because the crash is random, I haven’t been able to reproduce it reliably on demand via systemctl suspend yet. I’ll keep cycling suspend/resume and will post full journals as soon as I catch a failing run.

It has been happening more often on wifi, so I just decided to shift to using Ethernet, hoping that would have fixed the issue, but it still exists, it was a "driver own failed" error before, I will try to look for older logs and will edit this reply with those if that would work.
I get the blue screen when it crashes with caps lock light blinking when using linux, and for linux-lts, the system just hangs with the caps lock light blinking.

This is my current boot system journal: https://0x0.st/KTSS.txt

I also noticed something weird, the crashes have been somewhat consistent after I play some game, on ethernet it is somewhat stable (2/10 crashes for almost the same issue with mt7921e). But with Wifi it would crash 9/10 times and I had to reboot till somehow I would get it back. I tried  seeing if this would because of some race condition with my gpu and the wifi module, but couldn't figure it out because how much ever I try to load them at different times, the issue still existed. Let me know if you need something else that would help you better understand the issue.

Offline

#5 2025-09-19 09:02:47

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

nvidia+supergfxd makes me a bit nervous, but first off all see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons (seriously)

Then re-enable the wifi and try to trigger the panic.


Ftr, I don't see any other wifi devices, so the increment has probably been due to previously losing the device.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#6 2025-09-19 19:50:10

loqs
Member
Registered: 2014-03-06
Posts: 18,690

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

https://gitlab.archlinux.org/archlinux/ … /issues/29 ?

Offline

#7 2025-09-20 15:50:39

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

nvidia+supergfxd makes me a bit nervous, but first off all see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons (seriously)

Then re-enable the wifi and try to trigger the panic.


Ftr, I don't see any other wifi devices, so the increment has probably been due to previously losing the device.


I don't have windows, I single boot arch haha. Yea, the increment happens if it doesn't find the device in the first attempt.

From all the forums and bugs I have seen, seems like a race condition with the kernel and the MT7921 driver, causing a issue with some pointer

Offline

#8 2025-09-20 17:35:21

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

loqs wrote:

Tried the precompiled version from here, still the issue persists, here is the current boot dmesg: https://0x0.st/KTGf.txt and journalctl: https://0x0.st/KTGp.txt

The dmesg continuosly loops for the driver own failed issue, It will cause the kernel to panic, but takes sometime.

Back on ethernet with wifi related things on blacklist

Offline

#9 2025-09-20 18:26:06

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

What is and why is there 

Sep 18 23:35:14 cursedpc ntfs-3g[2529]: Mounted /dev/nvme1n1p1 (Read-Write, label "Storage", NTFS 3.1)

?


Sep 20 18:06:19 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 18:13:44 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 18:13:54 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 18:14:25 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 18:14:29 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 19:18:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:20:45 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:21:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:27:15 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:27:50 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:28:04 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:28:40 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:29:47 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:30:11 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 19:30:12 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier

Is this you actively pulling and plugging the rj45 cable?

Sep 20 19:29:42 cursedpc sudo[13837]: serendeep : TTY=pts/2 ; PWD=/home/serendeep ; USER=root ; COMMAND=/usr/bin/networkctl reconfigure wlan0
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session opened for user root(uid=0) by serendeep(uid=1000)
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: Reconfiguring with /etc/systemd/network/20-wlan.network.
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCP lease lost
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCPv6 lease lost
Sep 20 19:29:42 cursedpc systemd[1]: Starting Hostname Service...
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Withdrawing address record for 192.168.0.19 on wlan0.
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.0.19.
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session closed for user root
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Interface wlan0.IPv4 no longer relevant for mDNS.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240::5938 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240:366f:24ff:fed9:5955 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv6 with address 2a02:908:2810:f240:366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Registering new address record for fe80::366f:24ff:fed9:5955 on wlan0.*.
Sep 20 19:29:45 cursedpc kernel: mt7921e 0000:03:00.0: Message 00020006 (seq 5) timeout
Sep 20 19:29:45 cursedpc systemd[1]: Started Hostname Service.
Sep 20 19:29:45 cursedpc systemd-hostnamed[13841]: Hostname set to <cursedpc> (static)
Sep 20 19:29:46 cursedpc kernel: mt7921e 0000:03:00.0: driver own failed
Sep 20 19:29:47 cursedpc kernel: mt7921e 0000:03:00.0: Timeout for driver own

The timeouts are a direct consequence of you running "networkctl reconfigure wlan0", what was that about? Is it just a reliable way to trigger this?

----
x-ref:
https://bbs.archlinux.org/viewtopic.php?id=306031
https://bbs.archlinux.org/viewtopic.php?id=307329
https://bbs.archlinux.org/viewtopic.php?id=306643

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#10 2025-09-20 18:40:26

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

What is and why is there 

Sep 18 23:35:14 cursedpc ntfs-3g[2529]: Mounted /dev/nvme1n1p1 (Read-Write, label "Storage", NTFS 3.1)

?


Sep 20 18:06:19 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 18:13:44 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 18:13:54 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 18:14:25 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 18:14:29 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 19:18:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:20:45 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:21:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:27:15 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:27:50 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:28:04 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:28:40 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:29:47 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:30:11 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 19:30:12 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier

Is this you actively pulling and plugging the rj45 cable?

Sep 20 19:29:42 cursedpc sudo[13837]: serendeep : TTY=pts/2 ; PWD=/home/serendeep ; USER=root ; COMMAND=/usr/bin/networkctl reconfigure wlan0
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session opened for user root(uid=0) by serendeep(uid=1000)
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: Reconfiguring with /etc/systemd/network/20-wlan.network.
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCP lease lost
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCPv6 lease lost
Sep 20 19:29:42 cursedpc systemd[1]: Starting Hostname Service...
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Withdrawing address record for 192.168.0.19 on wlan0.
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.0.19.
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session closed for user root
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Interface wlan0.IPv4 no longer relevant for mDNS.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240::5938 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240:366f:24ff:fed9:5955 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv6 with address 2a02:908:2810:f240:366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Registering new address record for fe80::366f:24ff:fed9:5955 on wlan0.*.
Sep 20 19:29:45 cursedpc kernel: mt7921e 0000:03:00.0: Message 00020006 (seq 5) timeout
Sep 20 19:29:45 cursedpc systemd[1]: Started Hostname Service.
Sep 20 19:29:45 cursedpc systemd-hostnamed[13841]: Hostname set to <cursedpc> (static)
Sep 20 19:29:46 cursedpc kernel: mt7921e 0000:03:00.0: driver own failed
Sep 20 19:29:47 cursedpc kernel: mt7921e 0000:03:00.0: Timeout for driver own

The timeouts are a direct consequence of you running "networkctl reconfigure wlan0", what was that about? Is it just a reliable way to trigger this?

----
x-ref:
https://bbs.archlinux.org/viewtopic.php?id=306031
https://bbs.archlinux.org/viewtopic.php?id=307329
https://bbs.archlinux.org/viewtopic.php?id=306643

networkctl reconfigure wlan0 -> ran this because I was still connected to wifi, but I was not getting internet, and yes I was replugging the ethernet to upload the logs, already referenced all the above, seems like an open issue atm

Offline

#11 2025-09-20 18:46:23

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

What is and why is there 

Sep 18 23:35:14 cursedpc ntfs-3g[2529]: Mounted /dev/nvme1n1p1 (Read-Write, label "Storage", NTFS 3.1)

?


Sep 20 18:06:19 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 18:13:44 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 18:13:54 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 18:14:25 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 18:14:29 cursedpc systemd-networkd[1470]: wlan0: Gained carrier
Sep 20 19:18:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:20:45 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:21:25 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:27:15 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:27:50 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:28:04 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:28:40 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier
Sep 20 19:29:47 cursedpc systemd-networkd[1470]: enp2s0: Lost carrier
Sep 20 19:30:11 cursedpc systemd-networkd[1470]: wlan0: Lost carrier
Sep 20 19:30:12 cursedpc systemd-networkd[1470]: enp2s0: Gained carrier

Is this you actively pulling and plugging the rj45 cable?

Sep 20 19:29:42 cursedpc sudo[13837]: serendeep : TTY=pts/2 ; PWD=/home/serendeep ; USER=root ; COMMAND=/usr/bin/networkctl reconfigure wlan0
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session opened for user root(uid=0) by serendeep(uid=1000)
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: Reconfiguring with /etc/systemd/network/20-wlan.network.
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCP lease lost
Sep 20 19:29:42 cursedpc systemd-networkd[1470]: wlan0: DHCPv6 lease lost
Sep 20 19:29:42 cursedpc systemd[1]: Starting Hostname Service...
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Withdrawing address record for 192.168.0.19 on wlan0.
Sep 20 19:29:42 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.0.19.
Sep 20 19:29:42 cursedpc sudo[13837]: pam_unix(sudo:session): session closed for user root
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Interface wlan0.IPv4 no longer relevant for mDNS.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240::5938 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Withdrawing address record for 2a02:908:2810:f240:366f:24ff:fed9:5955 on wlan0.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Leaving mDNS multicast group on interface wlan0.IPv6 with address 2a02:908:2810:f240:366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::366f:24ff:fed9:5955.
Sep 20 19:29:45 cursedpc avahi-daemon[1683]: Registering new address record for fe80::366f:24ff:fed9:5955 on wlan0.*.
Sep 20 19:29:45 cursedpc kernel: mt7921e 0000:03:00.0: Message 00020006 (seq 5) timeout
Sep 20 19:29:45 cursedpc systemd[1]: Started Hostname Service.
Sep 20 19:29:45 cursedpc systemd-hostnamed[13841]: Hostname set to <cursedpc> (static)
Sep 20 19:29:46 cursedpc kernel: mt7921e 0000:03:00.0: driver own failed
Sep 20 19:29:47 cursedpc kernel: mt7921e 0000:03:00.0: Timeout for driver own

The timeouts are a direct consequence of you running "networkctl reconfigure wlan0", what was that about? Is it just a reliable way to trigger this?

----
x-ref:
https://bbs.archlinux.org/viewtopic.php?id=306031
https://bbs.archlinux.org/viewtopic.php?id=307329
https://bbs.archlinux.org/viewtopic.php?id=306643

The ntfs disk is a storage disk that has all my backups and development files, has no active windows installation though. Driver timeout is a reliable way for the panic to happen

Offline

#12 2025-09-20 21:32:45

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

Please avoid bloating the thread w/ pointless full quotes and also don't bump, edit your previous post to mend it if nobody has replied yet to not feign activity on the thread.

Can you replicate the initial connection failure w/o any docker instances running?
(Notably virbr0 and docker0 not riding on wlan0)

If yes, try to add "pcie_aspm=off" to disable that overall.

When the network fails, what are the symptoms?
Eg. what happens for "ping 192.168.0.1"?

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#13 2025-09-20 21:52:26

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

Please avoid bloating the thread w/ pointless full quotes and also don't bump, edit your previous post to mend it if nobody has replied yet to not feign activity on the thread.

Can you replicate the initial connection failure w/o any docker instances running?
(Notably virbr0 and docker0 not riding on wlan0)

If yes, try to add "pcie_aspm=off" to disable that overall.

When the network fails, what are the symptoms?
Eg. what happens for "ping 192.168.0.1"?

Apologies for before, No I cannot replicate the before, it is very random, I can reproduce the crash with wifi reliably most of the time, the driver own just keeps looping infinitely and then at one point the kernel panics and I get the blue screen. When I ping 192.168.0.1, I just get connection cannot be established even when according to iwctl, I am still connected to the internet.

Edit 1:
https://hastebin.skyra.pw/wojabolelo.prolog
https://hastebin.skyra.pw/lasufetefo.yaml

Some of the previous kernel panic reports

Last edited by thecursedapple (2025-09-20 22:05:44)

Offline

#14 2025-09-20 22:07:19

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

connection cannot be established

That's not a ping error, please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
There're worlds between "TTL Expired in Transit" "Destination Host Unreachable" "Request Timed Out" and "Unknown Host" and whatever else you might get.

I cannot replicate the before, it is very random, I can reproduce the crash with wifi reliably most of the time

Errr…?
The plan would be to reproduce the crash while using the wifi but not running any docker container to take the bridge out of the equation.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#15 2025-09-21 00:57:31

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

connection cannot be established

That's not a ping error, please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
There're worlds between "TTL Expired in Transit" "Destination Host Unreachable" "Request Timed Out" and "Unknown Host" and whatever else you might get.

I cannot replicate the before, it is very random, I can reproduce the crash with wifi reliably most of the time

Errr…?
The plan would be to reproduce the crash while using the wifi but not running any docker container to take the bridge out of the equation.

- The error I get with pinging is Destination Host Unreachable.
- Also figured out why wlan(x) and why x increasing. It increases on resuming from suspend.

I am trying to replicate the panic with both docker service enabled and disabled

This is with docker enabled: https://0x0.st/KT5H.txt ( sudo journalctl -b -1 | curl -F 'file=@-' https://0x0.st )
https://hastebin.skyra.pw/lecileyale.yaml (The kernel panic)

Trying it with docker disabled, also this is my current boot journal: https://0x0.st/KT5X.txt (The wifi didn't start and iwctl doesn't find my device anymore, this gets fixed if I keep rebooting and randomly start working, will keep updating this post with that boot journal as well)

Offline

#16 2025-09-21 07:05:41

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

The wifi didn't start and iwctl doesn't find my device anymore

Take the system completely off power (remove the battery) for a couple of minutes…

Sep 21 02:39:52 cursedpc (udev-worker)[8393]: wlan0: Process '/usr/bin/ethtool -K wlan0 gro off gso off tso off lro off' failed with exit code 92.

What is this? ethtool will not work w/ wifi devices

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#17 2025-09-21 11:30:37

Hasenblut
Member
Registered: 2010-09-08
Posts: 4

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

Causing a kernel panic is just something a mt7922 device likes to do in my experience: I have collected some qr blue-screens:
kernel 6.14.9
kernel 6.15.4
kernel 6.15.5
kernel 6.15.8
kernel 6.16.0
kernel 6.16.1
kernel 6.16.2
kernel 6.16.3
kernel 6.16.4
kernel 6.16.4
kernel 6.16.5
kernel 6.16.7
kernel 6.16.8
bonus panics from journalctl
and these were only the ones producing logs, because there were a lot of additional hard freezes.  If I attribute every unsave shutdown of my ssd to a mt7922 panic, it's roughly every 23 hours of runtime.

Some of these panics were after 10 minutes with no suspend, other after a week with 10s of suspends. I have no idea what causes them, how to mitigate them or how to reproduce them as they seem truly stochastic. It could be some corner case only present in some regulatory domain or connecting to certain routers, but something from the hard- or firmware makes the kernel driver acting up.  And given that mediatek just shipped a broken firmware for these devices I have low confidence this will ever get fixed. For completeness sake inxi -bxxx output.

Last edited by Hasenblut (2025-09-21 11:33:41)

Offline

#18 2025-09-21 17:34:53

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

Sep 21 02:39:52 cursedpc (udev-worker)[8393]: wlan0: Process '/usr/bin/ethtool -K wlan0 gro off gso off tso off lro off' failed with exit code 92.

What is this? ethtool will not work w/ wifi devices

No clue, I did not run it manually, some process is running it, I guess?

Offline

#19 2025-09-21 19:17:27

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

It's gonna be some udev rule, https://wiki.archlinux.org/title/Udev#I … udev_rules

grep -r ethtool /{etc,usr/lib}/udev/rules.d/

Did you

seth wrote:

Take the system completely off power (remove the battery) for a couple of minutes…

?

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#20 2025-09-22 15:01:01

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

It's gonna be some udev rule, https://wiki.archlinux.org/title/Udev#I … udev_rules

grep -r ethtool /{etc,usr/lib}/udev/rules.d/

grep -r ethtool /{etc,usr/lib}/udev/rules.d/
/etc/udev/rules.d/80-wifi-offloads.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/ethtool -K $name gro off gso off tso off lro off"

Did you

seth wrote:

Take the system completely off power (remove the battery) for a couple of minutes…

?

Yes, have to test out with docker disabled yet, was caught with some work, will try and update the same.

https://gitlab.archlinux.org/archlinux/ … ote_324258
Will try this first and update whether that resolves the issue

Last edited by thecursedapple (2025-09-22 15:04:10)

Offline

#21 2025-09-22 15:03:11

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

pacman -Qo /etc/udev/rules.d/80-wifi-offloads.rules

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#22 2025-09-22 15:04:57

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

pacman -Qo /etc/udev/rules.d/80-wifi-offloads.rules

error: No package owns /etc/udev/rules.d/80-wifi-offloads.rules

Offline

#23 2025-09-22 15:11:08

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 70,964

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

So, where's this coming from? In doubt move it away, idk what the ethtool attempt would do to the device (though ideally "nothing")

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#24 2025-09-22 15:16:35

thecursedapple
Member
Registered: 2025-09-18
Posts: 12

Re: Kernel panic in mt76/mt7921 on ASUS TUF A17 (MT7921e)

seth wrote:

So, where's this coming from? In doubt move it away, idk what the ethtool attempt would do to the device (though ideally "nothing")

I have no clue, I'll move it away, shouldn't ideally be the issue from what I understand.

Offline

Pages: 1

Board footer

Powered by FluxBB