For the individuals who didn't see my previous post, it's linked here for context.

When I finally got that sleep issue to fix, I was elated. I'd been working at the issue for hours, I was tired, and I wanted to share the fix with others. I thought I'd fixed the issue. I was wrong.

Or, well, mostly wrong.

The issue I was having (entering suspend and then failing to wake) was fixed, but the original delay in wake was, apparently, a different issue. Bizzarrely, for the first half an hour after the iommu=pt fix, the laptop woke exactly as expected. The next morning, though, it was right back to its original issue.

Now, to describe what that issue is. My laptop properly and consistently wakes after suspend now, and it wakes consistently, but there is a long delay after every single wake attempt. The display takes about 15 seconds for the display to enable.

Both the last delay, and the current delay appear across multiple Linux distros based on Arch, Debian-based, and RHEL. This includes all of the officially supported distros I've tested: Ubuntu 22.04 LTS, Ubuntu 25.04, Ubuntu 25.10, and Fedora 43, as well as between multiple desktop environments, using both X11 and Wayland.

Now without further ado, join me in my journey to attempt to fix this new issue.

System Info

Laptop: Framework 16 AMD Ryzen 7040 Series

CPU: AMD Ryzen 9 7940HS

GPU: RX 7700S (GPU Expansion Module)

RAM: 96GB DDR5-5600: Crucial 2×48 GB.

Storage: 2TB WD_BLACK SN770 (M.2 2280) and a 2TB WD_BLACK SN770M (M.2 2230). Both on firmware 731130WD.

BIOS: Multiple BIOS versions. Current is 03.07, dated 2025-08-27

Suspend mode: s2idle / Low-power S0 idle

Boot setup: rEFInd that boot into various distros. Each distro uses its own grub install.

The Troubleshooting Part

Was it the Kernel?

My first assumption was that there had been some kind of Kernel issue, so I checked suspend/resume logs using monotonic timestamps (the fancy new terms I get to learn are my favourite part of troubleshooting). The logs showed that once resume began, the kernel reached PM: suspend exit almost immediately. The resume path wasn't the cause of the delay.

Was it the Expansion Cards?

The logs showed some DRM hotplug/change events (that I suspected were probably normal), but I went ahead and tried sleep/wake while all of them were unplugged. This had no effect.

What About PCIe Issues?

The first new thing I noticed when checking the logs (which was an old thing I'd forgotten about in my initial troubleshooting over a year ago), was that log lines suggested instability and issues with PCIe-attached cards during sleep/wake. The dGPU and Wi-Fi cards both complained. While at that time I was using the Wi-Fi card that came with the Framework, it started having bluetooth connection issues, so I replaced it with a Qualcomm card.

So Is It Wi-Fi and Bluetooth?

While I was skeptical this was the cause of the issues, since I was using an entirely new Wi-Fi card, I didn't want to do anything but my due diligence, so I ran tests anyways. Besides, I found it a little unusual that they weren't immediately available on wake (it only began to try to connect when the display turned on).

The NetworkManager logs showed a consistent pattern:

NetworkManager wake is requested. Almost immediately after, wlp5s0 becomes available/disconnected. Roughly 15 seconds pass, and then NetworkManager attempts to connect to the saved connection (and succeeds).

I tested a forced reconnect hook to see whether manually bringing the connection up after resume would change the behavior.

The first hook ran too early. It attempted to activate the connection before NetworkManager had finished waking and re-managing the Wi-Fi interface. Running it with a short delay (1 or 2 seconds, I don't remember), I got the following result:

1wlp5s0 wifi unmanagedp2p-dev-wlp5s0 wifi-p2p unmanaged

So, nmcli was failing because the device was still strictly unmanaged.

That didn't end up doing what I'd initially intended, since the sleep hook ran before NetworkManager had completed its wake handling, but it gave me enough information to move on. After all, this showed that Wi-Fi and Bluetooth were already working when the display finally turned on.

The Wi-Fi card was not the culprit.

It Was the dGPU, Wasn't It?

At this point, I was nearly certain the issue was the Radeon dGPUmodule. Every single log that I looked through showed an identical error at a similar time:

amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes

I was fairly certain this was the dGPU, but just in case I mapped the DRM devices and confirmed it. card1 / renderD128 = 03:00.0 = Radeon 7700S dGPUcard2 / renderD129 = c5:00.0 = Phoenix iGPU. I include this line exclusively because I didn't know that the iGPU was called 'Phoenix,' and I thought that was pretty cool.

I then checked which processes were holding the dGPU open. lsof showed that several processes had handles to the dGPU, including Xorgplasmashellwaywallen. I killed Waywallen, then checked the dGPU runtime power state again, and it read suspended.

Now at this point, I knew this wasn't going to fix it (since I installed Waywallen all of two days ago), but I went ahead and tried anyway. As expected, the same Cannot find any crtc or sizes message was in the logs. That didn't fix it. At this point, I grew a brain and realised I could just remove the dGPU, so I did. I shut down the computer, yoinked out the Expansion Module, turned the laptop back on, and attempted sleep. I was already preparing to bite the tragedy and just deal with the issue because of a faulty expansion module.

The dGPU did not fix the issue.

Postlogue

At this point, I'm just tired. I have no idea what the problem is. I couldn't figure out what it was whenI first tried fixing it, I couldn't figure it out today, even after hours of troubleshooting and attempted fixes in every area I could think of. At this point, I think I'm probably stuck. I could contact support, but they probably won't do anything because I didn't contact support within the warranty window (my fault, I realise I should have done that, instead of trying to suppress and ignore the issue).

Kernel resume itself appeared fast once wake began. Wi-Fi had a visible reconnect delay in NetworkManager logs, but Wi-Fi connected quickly once activation started. The 15-second delay there matching with the 15-second time from power button press to display activating meant that there also isn't some inexplicable delay from the power button to the kernel starting wake. The touchpad showed I2C HID resume errors, but reloading the touchpad-related modules around suspend did not improve the wake delay. Fresh installs of compatible OSes, DEs, and using X11 or Wayland all failed to make a difference. Removing expansion cards did not improve the issue. Software wasn't causing the sleep issues by keeping the dGPU awake, and it wasn't the dGPU anyways, since physically removing the Radeon 7700S dGPU didn't fix the wake delay.

I have no idea what else to point fingers at, and I'm kind of exhausted.

If people happen to have any advice, that would be greatly appreciated. Especially if you've had this problem and been able to fix or reduce it. It's not like it's a huge problem, but it can be really frustrating to close it for a brief interruption, and then wait 15 seconds before I can start using my computer again.

So, my Framework 16 (AMD Ryzen 7040 Series) has had a continuing issue since the day I got it. On any linux-based operating system (Ubuntu, Mint, Fedora, Kali, and Arch, to name a few I tested), the device had a very long wake delay, that eventually became a full failure to wake. The issue persisted across desktop environments, kernel versions, and on distributions that were fully supported by Framework.

When I initially attempted fixes, I wasn't able to isolate or resolve the issue. I ended up entirely disabling all sleep/wake behaviour as a brute force, easy fix. For a long time that largely worked, as I used my computer plugged in and shut it off at night, but it was still a frustration to do on every distribution I was using.

Today, I finally fixed the issue (on Arch linux, at least. I'll be testing it on my other distros in a bit). I hadn't seen anybody post a solution or workaround anywhere I could find, so I figured I could post what I did here as a bit of a guide.

Mods, if this is the wrong flair, feel free to change it.

TL;DR, I added the iommu=pt parameter to /etc/default/grub. After adding that parameter, sleep and wake worked for the first time since I got this computer.

I'm not sure what exactly was causing the issue, but I think the fact that this works (plus some log information I gathered before the fix) indicates it was probably an AMD IOMMU/PCIe issue during s2idle.

System Info

Laptop: Framework 16 AMD Ryzen 7040 Series

CPU: AMD Ryzen 9 7940HS

GPU: RX 7700S (GPU Expansion Module)

RAM: 96GB DDR5-5600: Crucial 2×48 GB.

Storage: 2TB WD_BLACK SN770 (M.2 2280) and a 2TB WD_BLACK SN770M (M.2 2230). Both on firmware 731130WD.

BIOS: Multiple BIOS versions. Current is 03.07, dated 2025-08-27

Suspend mode: s2idle / Low-power S0 idle

Boot setup: rEFInd that boot into various distros. Each distro uses its own grub install.

Symptoms

Initially wake time was just long (2-5 minutes to exit sleep), but it would typically wake after some time. I'm not sure exactly when that behaviour stopped (since for a while sleep was disabled), but upon more recent linux installs, found that in all cases, the computer would never leave suspend. The effect was identical regardless of what caused sleep. The general pattern is below:

1. Display turns off

2. RGB keyboard and macropad switch on and off, then turn fully off

Then I'd try to wake it (lifting lid, tapping keyboard, pressing power button, etc.)

3. Power light flashed

4. Keyboard and micropad began to stutter on (macropad first, then keyboard)

5. Both eventually go dark

6. Display never remained off, and system was entirely unresponsive (power light wouldn't change, closing the lid didn't change behaviour, etc.) The only way to regain functionality was to force shutoff by holding the power button. Then, everything would work until the next sleep.

Originally, the laptop would take an extremely long time to wake from suspend. Sometimes it seemed like it might eventually come back after minutes.

When I began troubleshooting, I triggered the sleep, shutdown the computer and booted back into Arch, and then started by checked the previous boot log for the failed issue. The last line was consistently `PM: suspend entry (s2idle). I set kernel parameters to log as verbosely as I know how, and that remained the same. My best guess at this point is that it just never suspends properly, and so reboot never happens. Although, I'm not certain why it used to work at all, in that case.

As the next troubleshooting step, I added the iommu=pt kernel parameter to the GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub, and sleep just... worked. After years of being frustrated that sleep didn't work and dealing with the extra power draw (or forgetting to shut it down at night, and having it discharge overnight), it was just... working.

The Actual Fix Part

Since iommu=pt fixed the issue, I've just left it there. Righ tnow, the full line in /etc/default/grub is GRUB_CMDLINE_LINUX_DEFAULT="iommu=pt"

That's literally it. If you're having the same issue, I'd find that file and make the same edit. Make sure to regenerate grub though. The command is sudo grub-mkconfig -o /boot/grub/grub.cfg on my Arch setup. Then test with cat /proc/cmdline or whatever your distro needs. The result should include the iommu=pt. If not, make sure you edited the right file, updated grup properly, and rebooted.

Distro Variation Notes

So, I'm fairly sure that grub parameters are basically always stored in /etc/default/grub, and you should be able to check that grub booted with the updated parameters using cat /proc/cmdline, so that should be the same everywhere. Updating and regenerating grub works differently on different distros though, so I'll throw the most common commands below for the sake of convenience:

Arch: sudo grub-mkconfig -o /boot/grub/grub.cfg

Debian-base (Ubuntu, Mint, Pop! OS, etc.): sudo update-grub

RHEL-base (Fedora, Oracle, CentOS, etc.): sudo grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg. Replacewith whatever your OS happens to use (redhat, fedora, oracle, etc.).

Sorry if there are any typos or formatting issues, I wrote this up pretty quick in a markdown file late last night from a bunch of my own random notes, and I'm a bit too busy to edit all of this super well after pasting it to Reddit.