Hardware (desktop PC, not a laptop):
- CPU: Intel Pentium Gold G6400 (Comet Lake), integrated Intel UHD 610 graphics (device ID 9ba8)
- 8GB RAM, Kingston SA400S37240G SSD
- Debian 13 (trixie), fresh install
- XanMod kernel 7.2.7-x64v2-xanmod1 (I use XanMod because on both Mint and Debian, audio sounded like a scratched/broken CD with the stock kernel, and this was the only fix I found for that; also tested Debian's stock 6.12 kernel to rule it out as the cause of the suspend issue, same result on both)
The problem:
After suspending manually (or via idle timeout) and waking up, the system doesn't recover the display. It stays completely black and unresponsive to anything (not even Ctrl+Alt+F2/F1). The machine is otherwise clearly "alive" (fans, LEDs, disk activity), but there's no way to get control back except a hard power-off.
What I've already ruled out:
- Not the kernel: tested both XanMod and Debian's stock kernel, exact same result. Also tried downgrading kernel versions, no change.
- Already updated the BIOS to the latest available version, no change.
- Not the current install or something I installed: did a completely clean reinstall of Debian (fresh partitions, no third-party apps) and it still happens.
- Not Debian-specific: had the exact same issue on Linux Mint before (both the suspend problem and the broken audio) — actually switched to Debian thinking it might be a Mint-specific problem, but both issues are identical on both distros.
- Confirmed with a Debian live USB that suspend/resume works fine there — which is bizarre because it seems to rule out pure hardware/BIOS causes.
- Ruled out a spurious wakeup from automatic hibernation (had the default ~2h HibernateDelaySec triggering a phantom resume midway; already neutralized it with HibernateDelaySec=1000000000 in sleep.conf.d).
Kernel parameters already tried (no luck, combined):
- pci=noaer (this did fix an unrelated 100% CPU issue from PCIe AER errors, but doesn't touch suspend)
- i915.enable_psr=0
- i915.enable_fbc=0
- i915.enable_dc=0
- mem_sleep_default=s2idle (also tried deep, this board's default, same result either way)
- Disabled RP06 and RP08 in /proc/acpi/wakeup (PCIe ports) just in case, no change
What stands out most is that the live USB suspends/resumes perfectly, but the real install (same hardware, same kernel when tested, updated BIOS) always fails — and this repeats identically across two different distros (Mint and Debian). That seems to rule out pure hardware/BIOS, but I can't figure out what differs between a live environment and a normal install that could be interfering with the i915 resume path.
Has anyone seen a similar pattern with Comet Lake + UHD 610 on a desktop build? Is there something specific to a regular install (some service, a loaded module, something in systemd-logind) that a live session wouldn't have, that could be interfering with i915's resume?
Thanks in advance, genuinely out of ideas at this point.