Framwork 16 does not wake up the SSD/NVME on Resume from Suspend

I have the Framework 16 AMD 7040, I use Arch/CachyOS.

When the computer resumes from suspend the SSD is gone and does not come back.

That means that logging back in is not possible. A running ‘dmesg -w’ shows many BTRFS errors – understandable.

Alas, the amd diagnosis tool is not helpful, as no report can be written. Actually the tool freezes the laptop even more so I cant even change to a console anymore.

I tried all tips I could find in the community, which I summerize thusly:

✗ nvme_core.default_ps_max_latency_us=0
✗ pcie_aspm=off
✗ nvme.noacpi=1
✗ rtc_cmos.use_acpi_alarm=1
✗ AMDGPU parameters (abmlevel, sg_display, dcdebugmask)
✗ Framework 16 udev rules
✗ Bluetooth workaround
✗ Unplug AC before suspend
✗ Different kernels (Std and LTS)
✗ Hibernate (tried only briefly, though. Not sure this would help if I got it running).

Any other thing I could try?

tt.


=== Kernel ===
6.18.8-3-cachyos

=== Hardware ===
Manufacturer: Framework
Product Name: Laptop 16 (AMD Ryzen 7040 Series)
Version: AJ

=== BIOS ===
04.03
12/22/2025

=== CPU ===
Architecture: x86_64
Model name: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
Thread(s) per core: 2
Core(s) per socket: 8

=== Memory ===
Mem: 60Gi 6,5Gi 50Gi 221Mi 4,5Gi 54Gi

=== NVMe SSD ===
Node Generic SN Model Namespace Usage Format FW Rev


/dev/nvme0n1 /dev/ng0n1 244254800377 WD_BLACK SN850X 1000GB 0x1 1.00 TB / 1.00 TB 512 B + 0 B 620361WD

mn : WD_BLACK SN850X 1000GB
fr : 620361WD
frmw : 0x14
mntmt : 273
mnan : 0
mnsudmq : 0

=== Kernel Parameters ===
BOOT_IMAGE=/@/boot/vmlinuz-linux-cachyos root=UUID=*** rw rootflags=subvol=@ nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 pcie_port_pm=off amdgpu.abmlevel=0 amdgpu.sg_display=0 amdgpu.dcdebugmask=0x410

=== Suspend Configuration ===
Available suspend modes:
[s2idle]
GPP0 wakeup status:
GPP0 S4 *disabled

=== GRUB Configuration ===
GRUB_CMDLINE_LINUX_DEFAULT=‘nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 pcie_port_pm=off amdgpu.abmlevel=0 amdgpu.sg_display=0 amdgpu.dcdebugmask=0x410’

=== Expansion Cards (USB/PCI) ===
00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel
00:04.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel
01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
c1:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15b9
c1:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15ba
c3:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c0
c3:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c1
c3:00.5 USB controller: Advanced Micro Devices, Inc. [AMD] Pink Sardine USB4/Thunderbolt NHI controller #1
c3:00.6 USB controller: Advanced Micro Devices, Inc. [AMD] Pink Sardine USB4/Thunderbolt NHI controller #2

=== Attempted Fixes (All Failed) ===
Kernel Parameters Tested:

  • nvme_core.default_ps_max_latency_us=0
  • pcie_aspm=off
  • nvme.noacpi=1
  • rtc_cmos.use_acpi_alarm=1
  • amdgpu.abmlevel=0 amdgpu.sg_display=0 amdgpu.dcdebugmask=0x410

Configuration Applied:

  • Framework 16 specific udev rules (50-framework16.rules)
  • Bluetooth workaround (rfkill-suspender.sh)
  • Unplugging AC power before suspend
  • NVMe power state set to 0 (max performance)

Kernels Tested:

  • Arch Linux 6.18.8-3-cachyos
  • CachyOS LTS kernel

Alternative Suspend Methods:

  • Hibernate (suspend-to-disk): System hangs with infinite spinner
  • AMD diagnostic tool (amd-s2idle): Cannot complete - SSD disappears during test

=== Symptom ===
After suspend (s2idle), system wakes but all filesystems disappear.
NVMe SSD (WD_BLACK SN850X) fails to resume from suspend.
System becomes unresponsive, requires hard reset (SysRq REISUB).
Issue occurs regardless of:

  • AC power state (plugged in or on battery)
  • Suspend duration (tested from seconds to hours)
  • Kernel version
  • Kernel parameters

=== Pre-Suspend Diagnostic (from amd-s2idle test) ===
All pre-suspend checks pass:
:white_check_mark: ASPM policy set to ‘default’
:white_check_mark: GPIO driver ‘pinctrl_amd’ available
:white_check_mark: PMC driver ‘amd_pmc’ loaded (Program 0 Firmware 76.96.0)
:white_check_mark: USB3 driver ‘xhci_hcd’ bound
:white_check_mark: USB4 driver ‘thunderbolt’ bound
:white_check_mark: System configured for s2idle
:white_check_mark: GPU driver ‘amdgpu’ bound
:white_check_mark: PC6 and CC6 enabled
:white_check_mark: SMT enabled
:white_check_mark: ACPI FADT supports Low-power S0 idle
:white_check_mark: LPS0 _DSM enabled
:white_check_mark: WLAN driver ‘mt7921e’ bound

Problem occurs during/after resume - NVMe device does not wake up.
System configuration is correct; issue is at hardware/firmware level.

=== Expected Behavior ===
System should suspend to s2idle and resume with all devices functional.
NVMe SSD should wake up and remain accessible after resume.

A good place to start is here:

Specifically the “no_console_suspend” kernel parameter. It lets you see more error logs, even if the disk does not store them.

If it helps, i have a FW16 amd 7840hs and 1tb sn850x ssd like you and resume works fine, so it should work for you.
I run without any grub/kernel params set.

Interesting. I will try that out.

For now I experimented with different kernels from other distros. I started with the install medium of CachyOS and… it worked!

After transferring the kernel parameters of the medium to my own boot entry it also worked! Hooray!

Here are the different lines:

NOT WORKING:

	linux	/@/boot/vmlinuz-linux-cachyos-lts root=UUID=*** rw rootflags=subvol=@  nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 pcie_port_pm=off amdgpu.abmlevel=0 amdgpu.sg_display=0 amdgpu.dcdebugmask=0x410

also NOT WORKING:

	linux	/@/boot/vmlinuz-linux-cachyos-lts root=UUID=*** rw rootflags=subvol=@  nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3

but WORKING:

linux    /@/boot/vmlinuz-linux-cachyos-lts root=UUID=*** rw rootflags=subvol=@ module_blacklist=pcspkr i915.modeset=1 amdgpu.modeset=1 nvme_load=yes

That means, that amdgpu.modeset=1 seems to come to the rescue. Having an AMD GPU means that the i915 switch is probably a no-op.

I’ll check further.