I’ve just installed Debian 13 trixie release candidate 3 on a new Framework 13 AMD 350. As fa as I can see the only thing not working correctly is suspend and hibernate.
Suspend attempts to happen then comes back to life again. Hibernate appears to do same but I haven’t looked into that as much yet.
Here’s output from “amd-s2idle test”
How long should suspend cycles last (seconds) (default 10)?
How long to wait in between suspend cycles (seconds) (default 4)?
How many suspend cycles to run (default 1)?
What format to output the report in (html, txt, md, stdout)? txt
💻 AMD Ryzen AI 7 350 w/ Radeon 860M (family 1a model 60)
💻 Framework Laptop 13 (AMD Ryzen AI 300 Series) (Laptop)
🐧 Debian GNU/Linux 13 (trixie)
🐧 Kernel 6.12.38+deb13-amd64
🔋 Battery BAT1 (NVT FRANGWA) is operating at 104.52% of design
✅ ASPM policy set to 'default'
✅ GPIO driver `pinctrl_amd` available
✅ PMC driver `amd_pmc` loaded (Program 11 Firmware 101.4.0)
✅ USB3 driver `xhci_hcd` bound to 0000:c1:00.4, 0000:c3:00.0, 0000:c3:00.3, 0000:c3:00.4
✅ USB4 driver `thunderbolt` bound to 0000:c3:00.5, 0000:c3:00.6
✅ System is configured for s2idle
✅ GPU driver `amdgpu` bound to 0000:c1:00.0
✅ PC6 and CC6 enabled
✅ SMT enabled
✅ IOMMU properly configured
✅ ACPI FADT supports Low-power S0 idle
✅ LPS0 _DSM enabled
✅ WLAN driver `mt7925e` bound to 0000:c0:00.0
🗣️ Started at 2025-08-08 16:17:31.250636 (cycle finish expected @ 2025-08-08 16:17:45.362186)
🗣️ Results from last s2idle cycle
Summary
╒═════════════════════╤════════════╤══════════════════╤═════════════════╤═════════════════╤════════════════════╤════════════╤══════════════════╕
│ Start Time │ Duration │ Hardware Sleep │ Battery Start │ Battery Delta │ Battery Ave Rate │ Wake Pin │ Wake Interrupt │
╞═════════════════════╪════════════╪══════════════════╪═════════════════╪═════════════════╪════════════════════╪════════════╪══════════════════╡
│ 2025-08-08 16:17:31 │ 0:00:00 │ nan% │ 78.79% │ nan% │ nanW │ │ │
╘═════════════════════╧════════════╧══════════════════╧═════════════════╧═════════════════╧════════════════════╧════════════╧══════════════════╛
Failed to set suspend state (3053 -> 3055): [Errno 110] Connection timed out
Report written to amd-s2idle-report-2025-08-08.txt
```
Full report: https://paste.debian.net/plainh/f6713ca2
In the system logs the only interesting thing around the time of attempt is:
```
Aug 08 16:17:45 brackla kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Aug 08 16:17:45 brackla kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 08 16:17:45 brackla kernel: wlan0: deauthenticating from d8:ec:5e:ab:64:33 by local choice (Reason: 3=DEAUTH_LEAVING)
Aug 08 16:17:45 brackla kernel: mt7925e 0000:c0:00.0: Message 00020007 (seq 11) timeout
Aug 08 16:17:45 brackla kernel: mt7925e 0000:c0:00.0: PM: pci_pm_suspend(): mt7925_pci_suspend [mt7925e] returns -110
Aug 08 16:17:45 brackla kernel: mt7925e 0000:c0:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -110
Aug 08 16:17:45 brackla kernel: mt7925e 0000:c0:00.0: PM: failed to suspend async: error -110
Aug 08 16:17:45 brackla kernel: PM: suspend of devices aborted after 3307.673 msecs
Aug 08 16:17:45 brackla kernel: PM: start suspend of devices aborted after 3318.121 msecs
Aug 08 16:17:45 brackla kernel: PM: Some devices failed to suspend, or early wake event detected
```
So, mt7925e would be the stock wifi. Didn't realise this was coming with a Mediatek and might have picked my own one if I'd known.
This is kernel 6.12.38+deb13-amd64 as shipped with Debian 13 RC3 including the Debian packaged firmware-mediatek listed as version 20250410-2.
Should I try the 6.16 kernel that is packaged in Debian experimental? Or an upstream kernel package?
Should I try the latest mediatek firmware? It seems there has been just a couple of updates in the last few months: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/mediatek/mt7925
Does anyone have this working already?
If I have to try another wifi card, what would be best? I have read AX210 is good for AMD laptops.
Thanks,
Andy
1 Like
firmware-mediatek in Debian experimental has a version of 20250708-1 so I tried that without success. It doesn’t seem likely that getting the files from git at the above link will have any more success.
So, probably a different wifi card is required. I’m hesitant to do that without any reports of others having success. I know that Framework test with Fedora and Ubuntu. Are there people having success there, with the MeidaTek card or others?
I use the mt7925 in an FW13 w/ HX 370 and have no problems. I’m on CachyOS w/ 6.16 though (and latest mediatek firmware).
2 Likes
I’ve had some success. So just in case any of this helps anyone…
Firstly, it definitely is the mt7925 driver causing me issues as if I remove it with modprobe -r mt7925e then both suspend and hibernate work fine. This is with the kernel that comes with Debian 13, at time of writing 6.12.38+deb13-amd64.
I was able to automate this to the point that I didn’t notice, by creating a file at /usr/lib/systemd/system-sleep/handle_mt7925e.sh:
#!/bin/sh
if [ "${1}" = "pre" ]; then
# about to suspend/hibernate
modprobe -r mt7925e
elif [ "${1}" = "post" ]; then
# about to resume
modprobe mt7925e
fi
And then make sure that file is executable. After that, whenever systemd tries to suspend or hibernate by whatever means it will do the modprobe for me.
I still didn’t like it though so I bought an AX210 card and fitted that and suspend/hibernate works fine without that hack.
Since there have been reports of success with mt7925e without any such hacks I suppose it must be a question of kernel version. I did not try a kernel from experimental nor an upstream kernel.
1 Like
Thanks! This worked for me as well on Manjaro.
I identified the mt7925 driver as the issue that was throwing errors in journalctl when trying to suspend/ hibernate.
I was near switching to a different distro, thanks for the fix 
1 Like
I had the very same issue on
Linux **** 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
I solved this using the following systemd service:
[Unit]
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
StandardOutput=syslog
RemainAfterExit=yes
ExecStart=modprobe -r mt7925e
ExecStop=modprobe mt7925e
[Install]
WantedBy=sleep.target
You can install the service by pasting the contents from above into the editor from systemctl edit --edit --force mt7925e-suspend.service. After saving the file and closing the editor, you have to reload the systemd daemon and enable the service: systemctl daemon-reload && systemctl enable --now mt7925e-suspend.service
You can verify the setup by running systemctl suspend, then, waking the system up again. If the output from systemctl status mt7925e-suspend.service says “status=0/SUCCESS” everything is working.
Loaded: loaded (/etc/systemd/system/mt7925e-suspend.service; enabled; preset: enabled)
Active: inactive (dead) since Wed 2025-10-22 14:38:33 CEST; 15min ago
Duration: 2min 17.351s
Invocation: 18e84562d30f48bfb38f62ddc6e91539
Process: 19645 ExecStart=modprobe -r mt7925e (code=exited, status=0/SUCCESS)
Process: 19670 ExecStop=modprobe mt7925e (code=exited, status=0/SUCCESS)
Main PID: 19645 (code=exited, status=0/SUCCESS)
Mem peak: 1.7M
CPU: 19ms
If you run into issues during the installation, you might have to manually load the kernel module to get wifi working again: modprobe mt7925e
1 Like
This was a known issue with the mt7921e and other related kernel driver on older kernels of Linux. Here is an example report from the kernel bugzilla. Here is me discussing it on Arch Linux forums. Basically, this is a known issue that is discoverable with a google search. I think nobody talks about it anymore since it was solved upstream by having the card reset itself after it wakes from suspend in kernel (I think, if the dmesg logs are anything to go by).
I personanlly made the following script:
#!/bin/bash
case in ${1} in
pre)
# Uncommon line to choose for either mt7921 or mt7925
#rmmod mt7921e mt7921-common mt7921x-lib mt76-connac-lib mt76
#rmmod mt7925e mt7925-common mt792x-lib mt76-connac-lib mt76
;;
post)
#modprobe mt7921e
#modprobe mt7925e
;;
esac
that you can put at /usr/lib/systemd/system-sleep/mediatek-suspend-fix.sh.
Another thing that helps a lot is using a newer kernel. You really should be using a newer kernel considering you have a new APU with new hardware in it. There are so many improvements, especially for the AMD graphics, power handling, and hetereogenous CPU support.
I’m rocking kernel 6.17.4 and currently don’t experience this issue anymore. Not with my mediatek mt7922 on my desktop, nor my mediatek mt7925 on my laptop.
Thanks worked for me too!
But I had to replace –edit with –full i.e.
sudo systemctl edit --force --full mt7925e-suspend.service
I just upgraded to the backported 6.16.3 kernel, and that solved the problem completely, without needing anything of the above