mt7921e (MT7921, 14c3:7961): `pci_pm_resume returns -110` ("Message 00020007 timeout") on every S3 resume, reproduced on vanilla Arch kernel (ThinkPad X13 Gen 1 AMD)

Open
  • Is something wrong?
#1,182 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
Over a week
Newbie friendliness
18/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
operating-systems

Research direction

The failing path is the mt7921e PCIe resume callback, which waits on an MCU message (0x20007) and times out; start from the mt7921 power-management and firmware-reload code in the mt76 tree and trace where the message timeout is returned. Reproducing needs a ThinkPad-class S3 suspend setup, so first confirm the timeout with dynamic debug for mt76. Done would mean the resume completes without -110 across repeated S3 cycles.

Written by the indexing model from the issue text.

Description

Summary

On every suspend-to-RAM (S3, mem_sleep = deep) the mt7921e PCIe resume callback fails with a 0x20007 MCU message timeout. The driver recovers afterwards (reloads firmware, Wi-Fi works normally), but the kernel waits for the failed async callback before restarting tasks, so after opening the lid the screen is on with a stale frame and input is dead for about 3-5 seconds.

It is 100% reproducible here, including on an unmodified Arch kernel: 18 of 18 suspend cycles without the workaround logged the failure (table below). The only resumes without it are the ones where the module was unloaded before suspend (see workaround).

Hardware / software

  • Laptop: Lenovo ThinkPad X13 Gen 1 (AMD), model 20UGS2YD00, Ryzen 5 PRO 4650U, BIOS R1CET85W (1.54) 03/25/2026
  • Adapter: MEDIATEK MT7921 802.11ax PCIe [14c3:7961], subsystem Lenovo e0bc, driver mt7921e
  • Distribution: CachyOS (Arch-based)
  • linux-firmware 20261019; loaded: patch build 20260224110909a, WM firmware ____010000 build 20260224110949, ASIC revision 79610010
  • Suspend mode: S3 (mem_sleep: s2idle [deep])

Kernels tested (resumes with the failure / total, no workaround)

Kernel Failed resumes
7.2.14-arch1-1 (vanilla Arch linux) 3 / 3
7.3.3-1-cachyos (CachyOS, EEVDF) 3 / 3
7.3.3-1-cachyos-bore-lto 1 / 1
7.3.0-2-cachyos-bore-lto 4 / 4
7.0.11-1-cachyos-bore-lto 6 / 6

Log (one resume)

mt7921e 0000:03:00.0: Message 00020007 (seq 3) timeout
mt7921e 0000:03:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
mt7921e 0000:03:00.0: PM: failed to resume async: error -110
mt7921e 0000:03:00.0: Loading firmware patch: mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260224110909a
mt7921e 0000:03:00.0: WM Firmware Version: ____010000, Build Time: 20260224110949
wlan0: Driver requested disconnection from AP 00:00:00:00:00:00
OOM killer enabled.
Restarting tasks: Starting
Restarting tasks: Done

What I tried

  • options mt7921e disable_aspm=1: no effect; the log says can't disable ASPM; OS doesn't have ASPM control (the firmware keeps ASPM control), and the timeout still occurs on resume.
  • Updating the kernel from 7.3.0-2 to 7.3.3-1: no change.

Workaround that works

A systemd-sleep hook that runs modprobe -r mt7921e before suspend and modprobe mt7921e after resume. With it there is no timeout, no freeze, and Wi-Fi is back within a few seconds.

Related reports (similar message, different power state or hardware)

  • #896: same Message 00020007 timeout / -110, on hibernate restore (MT7922, Framework 13); closed, but a later comment says it still happens on 6.12
  • #1110: mt7921e after s2idle resume (firmware stops silently, no timeout logged)
  • #1180: MT7902 after s2idle resume

Question

Is there a debug option or a patch to try? I can build and test patches and collect extra logs (for example with dynamic debug for mt76), as this reproduces on every suspend.

Dominant language
C
Stars
895
Forks
461
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/mt76

All issues in openwrt/mt76

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.