mt7921e on Ryzen 5800H: intermittent driver-own/PCIe failure; AER + drv_pmctrl fixes prevent panic but device still wedges

This is a hardware failure report with five open questions, not a scoped change: start by reading the driver-own handshake in mt7921 (mt7921_mac_resume / driver own acquire) and the reset path reached from mt7921_mac_reset_work, plus the two cited commits (mt76 bd9cca0a and 8e856ad9) to see what they already contain. Answering Q4/Q5 — the PCI_COMMAND/MSI loss while the endpoint stays enumerated — is the most tractable slice, by tracing where endpoint config state is restored after reset in mt7921_pci.c. Done looks like a concrete diagnosis or a targeted patch/debug patch posted to the issue thread; note the reporter has no captured lspci outputs or configs attached yet, so requesting those is a prerequisite.

Hardware

• Laptop: ASUS TUF Gaming A15 FA506QM
• CPU: AMD Ryzen 7 5800H / Cezanne
• Wi-Fi: MediaTek MT7921 PCIe [14c3:7961]
• MT7921 PCI address when healthy: 0000:03:00.0
• AMD upstream root port: 0000:00:02.2
• GPU: NVIDIA RTX 3060 Mobile
• BIOS: FA506QM.316

Summary

I have an intermittent MT7921 PCIe failure where the device stops responding, MCU commands time out, driver own failed repeats, and reset attempts fail.

On unpatched kernels this has sometimes escalated into a complete system freeze/reboot or kernel panic in the mt76 DMA/reset path.

I built a custom kernel containing two accepted MT7921 fixes. This dramatically improves survivability: the underlying Wi-Fi failure can still occur, but during the captured incident the operating system remained usable and USB tethering continued working.

The failure is not suspend-specific. Several incidents have occurred shortly after ordinary boot or during normal use.

Typical failure sequence

A contained failure showed repeated messages such as:

mt7921e 0000:03:00.0: Message 00020006 (...) timeout
mt7921e 0000:03:00.0: driver own failed
...
mt7921e 0000:03:00.0: chip reset failed

During one captured incident there were:

• 50 driver own failed messages
• 5 chip reset failed messages
• 28 MCU timeouts

Previous unpatched panic

On linux-omarchy 7.2.5-3 I captured a panic in the MT7921 reset work:

Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
RIP: mt76_dma_add_buf.isra.0+0x9c/0x230 [mt76]
...
mt76_dma_tx_queue_skb_raw
mt76_mcu_skb_send_and_get_msg
mt76_connac_mcu_uni_add_dev
mt7921_vif_connect_iter
...
Kernel panic - not syncing: Fatal exception in interrupt

This appears consistent with the invalid/all-ones DMA state described by the MT7921 AER/DMA safety fix.

Custom containment kernel

I reconstructed the exact Omarchy linux-omarchy 7.2.5-3 source/configuration and applied only these two MT7921 fixes:

1. PCIe AER / invalid-DMA / bus-hung protection

   Linux commit:

   915672c5ae32deeb72f4572856d123f314791136

   mt76 origin:

   bd9cca0a3c39364af411d7c2ad2a862df69c9d3c

2. Abort PCIe reset after failed driver-own acquisition

   mt76 commit:

   8e856ad93d3af52224a9e369a62181626efc2a42

Resulting kernel release:

7.2.5-3-omarchy-mt7921test

This is by far the most stable configuration I have tested.

It does not eliminate the underlying MT7921 wedge, but in the one captured failure on this kernel the OS survived.

PCI state during contained failure

The MT7921 remained enumerated and bound at 03:00.0, and the AMD root port remained present.

However, the endpoint showed:

PCI_COMMAND = 0000
Mem-
BusMaster-
MSI disabled
BAR decoding disabled

while Linux still retained driver/IRQ bookkeeping.

Endpoint status included:

DevSta: CorrErr+ NonFatalErr+ UnsupReq+
UESta: Unsupported Request
CESta: replay rollover / replay timeout / advisory nonfatal

The root port remained:

5 GT/s x1
DLActive+

No MT7921 AER-handler messages appeared during this event.

The root port did not appear to expose a usable native AER service for this device path, so the driver's AER recovery callbacks were not invoked.

Kernel matrix

I have observed the same underlying failure class on:

• Arch 7.1.9.arch1-2
• Arch 7.2.3.arch1-3
• Omarchy 7.2.5-3
• Arch 7.2.6.arch2-1
• Linux LTS 6.18.49-3
• Arch 6.17.9.arch1-1

The custom 7.2.5-3-omarchy-mt7921test kernel with the two fixes above is the only configuration that has provided consistently good OS survivability so far.

Other experiments

These did not eliminate the underlying failure:

• MT7921 runtime PM disabled
• ASPM disabled
• Wi-Fi powersave disabled
• rollback to February 2024 MediaTek firmware
• multiple kernel generations

One AMD Data Fabric reset also occurred with mt7921e blacklisted while the MediaTek Bluetooth function remained active, so I cannot conclude that the Wi-Fi function alone is the root cause.

AMD reset evidence

After multiple catastrophic incidents the AMD reset reason was:

0x08000800

This has been decoded as an uncorrected error causing a Data Fabric sync flood event.

In some severe incidents the 00:02.2 root port and MT7921 endpoint were missing from PCI topology after reboot until further rebooting or a full power cycle.

Related issue

This looks similar in failure shape to issue #681, which also involved a Ryzen 7 5800H + MT7921 and repeated driver own failed / reset failures.

Questions

1. Is this driver-own / PCI configuration-loss failure a known MT7921 issue?
2. Is there existing or in-flight work intended to prevent the device from entering this state, rather than only containing the subsequent reset?
3. Is commit 8e856ad93d3af52224a9e369a62181626efc2a42 expected to be sent to stable kernels?
4. Is there additional tracing/debugging that would be useful the next time I capture the device alive but wedged?
5. Is the loss of PCI_COMMAND/MSI state while the endpoint remains enumerated a known MT7921 failure mode?

I can provide:

• full unpatched panic log
• full contained-failure kernel journal
• lspci -vv output for both 03:00.0 and 00:02.2
• exact kernel configuration
• exact package/build information
• exact two-patch diff