mt7615e (MT7663, 14c3:7663): Wi-Fi unusable after s2idle resume, only a full reboot recovers; hot unbind hangs the system; ROM patch fails to load on 7.0

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

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
networking, operating-systems

Research direction

Start in mt7615/mcu.c around the patch-load path (search for 'Failed to get patch semaphore') and the suspend/resume hooks in mt7615/pci.c and mt7615/mmio.c, comparing kernel 6.14 vs 7.0 behavior for message timeouts during wiphy_resume. First step: enable mt76 debug logging and reproduce with rtcwake -m freeze -s 25 or systemctl suspend, then trace why Message 000046ed never gets a reply after resume. Done means wiphy_resume returns 0 and the patch loads on 7.0 without reboot — but note the reporter's exact hardware is required to verify, and hot-unbind hangs make this risky to debug blind.

Written by the indexing model from the issue text.

Description

Hardware / software
  • Laptop: Acer Aspire A315-24P, BIOS V1.28 (05/20/2026), AMD Ryzen 5 7520U
  • Card: 02:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7663], subsystem Lite-On [11ad:3801], driver mt7615e
  • OS: Linux Mint 22.3 (Ubuntu 24.04 base)
  • Kernels tested: 6.14.0-37-generic and 7.0.0-38-generic (Ubuntu HWE)
  • linux-firmware: 20240318.git3b128b60.0ubuntu3.1
  • Sleep: only s2idle is available (/sys/power/mem_sleep = [s2idle])
  • The same laptop never had this problem under Windows.
Problem 1: Wi-Fi is broken after resume from s2idle

After any suspend/resume (lid close or systemctl suspend), the link is effectively dead. NetworkManager still reports the connection as up (CONNECTIVITY full), but:

  • the first ~5–40 s nothing passes at all (gateway, internet, DNS);
  • after that, traffic is intermittent for minutes: ping to the gateway on the same LAN goes from ~2 ms before suspend to 2.5–6.4 s, with packet loss; throughput drops from ~370 Mbit/s to ~0.1 Mbit/s;
  • it does not recover on its own (observed for over 4 minutes);
  • toggling Wi-Fi off/on or reconnecting in NetworkManager does not help;
  • only a full reboot recovers the card.

Kernel log on 7.0.0-38 across one suspend/resume:

[  148.986833] PM: suspend entry (s2idle)
[  171.559711] mt7615e 0000:02:00.0: Message 00020007 (seq 13) timeout
[  192.039578] mt7615e 0000:02:00.0: Message 000046ed (seq 14) timeout
[  192.042297] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -110
[  192.042364] ieee80211 phy0: PM: failed to resume async: error -110
[  192.621184] PM: suspend exit
[  318.503506] mt7615e 0000:02:00.0: Message 000046ed (seq 15) timeout
[  338.982907] mt7615e 0000:02:00.0: Message 000046ed (seq 1) timeout

On 6.14.0-37 the same symptom happens after resume, but without the Message … timeout lines. Instead there are repeated authentication timeouts to the AP.

Reproduce: set an RTC wake alarm (echo +30 > /sys/class/rtc/rtc0/wakealarm) and run systemctl suspend. It reproduces every time. rtcwake -m freeze -s 25 reproduces it too.

What was tried (none worked)
  1. d3cold_allowed=0 on 0000:02:00.0. The device stays in D0 across suspend, and the result is the same broken link.
  2. A systemd-sleep hook running modprobe -r mt7615e (pre) and modprobe mt7615e (post), with systemctl suspend. The machine froze/rebooted while entering suspend, and nothing more was written to the journal. It is not clear whether the unload or the suspend itself triggered it.
  3. PCI remove + rescan while the link was already broken (echo 1 > /sys/bus/pci/devices/0000:02:00.0/remove; echo 1 > /sys/bus/pci/rescan). The machine froze/rebooted immediately, and the journal ends abruptly.

So the card cannot be re-initialised without a full reboot, and hot-unbinding it hangs the system.

Problem 2: ROM patch fails to load on 7.0.0-38 at every boot

On every boot with 7.0.0-38 (5 of 5 boots):

mt7615e 0000:02:00.0: Failed to get patch semaphore
mt7615e 0000:02:00.0: mediatek/mt7663pr2h.bin not found, switching to mediatek/mt7663pr2h_rebb.bin
mt7615e 0000:02:00.0: Failed to get patch semaphore
mt7615e 0000:02:00.0: failed to load mediatek/mt7663pr2h_rebb.bin

The pattern repeats ~10 times, and no HW/SW Version line is printed. With 6.14.0-37 (2 of 2 boots) the patch loads normally:

mt7615e 0000:02:00.0: HW/SW Version: 0x65326363, Build Time: 2006030247debug
mt7615e 0000:02:00.0: N9 Firmware Version: 3.1.1, Build Time: 20200604161656

Even so, Wi-Fi on 7.0 works at full speed after a fresh boot. The files are present: mt7663pr2h.bin.zst and mt7663pr2h_rebb.bin.zst in /lib/firmware/mediatek/.

Possibly related

Happy to test patches or collect more logs (e.g. with mt76 debug enabled).

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.