Solved - Framework 16 OPAL/SED Drive Causing System Freeze on Resume (Fedora Silverblue)

Framework Laptop 16 Linux
1

Laptop: Framework 16 (Ryzen 7840HS CPU, Radeon 780M iGPU and Radeon RX 7700S dGPU)
OS: Fedora Linux 43.20260116.0 (Silverblue)
Drive: Samsung 990 PRO with OPAL SED enabled (Shadow MBR) + LUKS encryption on top, with nvme firmware version 8B2QJXD7

The Problem

After resuming from suspend, my system would become completely unresponsive. I could move the mouse cursor, but all applications were frozen and I couldn’t interact with anything. The system would eventually require a hard power-off. If I initiated the suspend from the shell (Ctrl-Alt-F3) I could resume back to the shell, but only use very basic commands in memory. Any attempts to read from the drive, including ls, or attempts to obtain an logs all provided a “input/output error”. After a reboot, there would be no log entries of what occurred. I ended up setting up remote logging to another machine, and struggled to get any useful log entries, there was some btrf errors and that moved my attention from the GPU to the NVME drive.

cat /sys/block/dm-0/power/runtime_status returns: unsupported

cat /proc/mounts shows a few dozen lines, but dm-0 is not listed

The Root Cause

When the system suspends, an OPAL SED drive re-locks itself. Upon resume:

  1. The NVMe controller comes back online

  2. The drive remains OPAL-locked (Locking Range 0 is engaged)

  3. The kernel attempts to access the dm-0 device but receives I/O errors

  4. BTRFS transactions fail because the underlying storage is inaccessible

  5. The filesystem is forced read-only, causing the apparent system freeze

The Solution

If I booted into the opal rescue image and use sedutil-cli to disable the OPAL encryption:

sedutil-cli --disableLockingRange 0  /dev/nvme1
sedutil-cli --setMBREnable off  /dev/nvme1

Dual encryption provides minimal additional benefits, and I suspect the OPAL keys have likely been leaked anyways, irrespective of this I will revisit this in future versions as Linux has experimental in-kernel OPAL support that may eventually handle unlock on resume.

Additional Notes

While troubleshooting, I tried various kernel parameters that did not solve the issue, a few prominent ones that kept appears in my searches were:

  • nvme_core.default_ps_max_latency_us=12000
  • nvme_core.default_ps_max_latency_us=0
  • pcie_aspm=off
  • mem_sleep_default=s2idle

These address NVMe power state problems, not OPAL locking behavior.

Hopefully this helps someone, cheers :slightly_smiling_face: