# Suspend/resume hangs with black screen on HP OMEN 16 (Ryzen 9 8940HX, s2idle) — NVIDIA ruled out, pm_trace points at amdgpu

Ask Fedora
, , ,
1

System:

  • HP OMEN Gaming Laptop 16-ap0xxx, BIOS F.11 (2025-12-16)
  • AMD Ryzen 9 8940HX (Raphael/Phoenix-class iGPU) + NVIDIA dGPU (currently hard-disabled via BIOS MUX, iGPU-only)
  • Fedora Linux 44 (Workstation), kernel 7.1.8-200.fc44.x86_64
  • cat /sys/power/mem_sleep → [s2idle] only, no deep — Modern Standby hardware, no real S3

Problem:

Every time I suspend, resume hangs completely: black screen, no response to keyboard/input, fans/LEDs suggest it’s powered on but the display never comes back. Only fix is a hard power-cycle. 100% reproducible, not intermittent. Happens the same way on both Fedora and CachyOS on this same laptop, so I don’t think it’s Fedora-specific — but posting here since Fedora’s my daily driver.

One extra clue: right after a resume attempt, the brightness Fn keys (bound directly by my compositor, not through a daemon) work for about 4 seconds and then stop. Looks like the EC/keyboard comes back first and then the GPU/display resume path deadlocks and takes the whole session with it.

journalctl -b -1 -r after a hard reboot never shows anything past PM: suspend entry (s2idle) — zero resume-path log lines, so the journal never gets a chance to flush before it hangs.

What I’ve already ruled out:

  • NVIDIA entirely — tried the usual driver power-management fixes (VRAM preserve across sleep, nvidia-drm.modeset=1, S0ix enable, GSP firmware disable, NVreg_DynamicPowerManagement=0x01 coarse runtime PM). None of it helped. Then disabled NVIDIA at the hardware level via the BIOS MUX switch (iGPU-only) — bug reproduces identically with NVIDIA completely out of the picture. So this isn’t an NVIDIA driver issue.
  • Audio codec power saving — snd_hda_intel.power_save=0, no effect.
  • amdgpu iGPU runtime PM racing suspend — checked /sys/bus/pci/devices/0000:05:00.0/power/control, it’s on (not auto-suspending), so this doesn’t look like the classic runtime-PM/suspend race.

What I’ve found so far:

Used the kernel’s pm_trace facility to get past the “nothing in the log” problem — it RTC-stamps the last device touched before the hang, and that survives a hard power-cut:

echo 1 | sudo tee /sys/power/pm_trace
suspend, let it hang, hard reboot

sudo dmesg | grep -i ‘hash matches’

Result: pci 0000:05:00.6: hash matches — that’s the AMD Ryzen HD Audio Controller (HDMI/DP audio function), which sits on the same PCI slot as the amdgpu iGPU (0000:05:00.0, “Onboard IGD”, driver amdgpu). Since disabling that audio codec’s power saving didn’t change anything, I think pm_trace is just naming the last device in enumeration order and the real hang is in the iGPU function itself or right next to it in the suspend/resume sequence.

Questions for the forum:

  • Anyone else with a Raphael/Phoenix-class AMD iGPU + s2idle-only hardware seeing the same black-screen resume hang?
  • Any known amdgpu suspend/resume bugs for this generation I should check against, or a good way to geng (drm.debug?) to narrow this past pm_trace’s “last device touched” limitation?
  • Is there a cleaner way than pm_trace to capture what’s happening right at the point of the hang, giv

Happy to run kernel debug builds, try drm.debug= flags, or bisect if pointed in a direction — just want to get past guessing at this point. Thanks.