12gen hard freeze on resume (KDE&Gnome)

i’ve been battling this issue for a few months now where the laptop will randomly freeze almost immediately after resume from sleep.

It’s completely random but can pretty much guarantee it will freeze 1in10 times, usually about 1in5. Good resumes have no weird behaviour

seems to be related to external connections, as when running on battery i cannot remember ever experienced the issue.

  • memtest ok
  • removed wifi card (AX201)
  • 3 different docks. Anker USB-C, Dell WD19TB, Lenovo TB3 dock (type 40AC)
  • multiple linux distros - Kubuntu, KDE Neon, Fedora 39,40 KDE spin (not sure if it occured on 38)
  • i dont recall it ever occuring on gnome (maybe tested on F39).
  • disconnected various docks before sleep appears to not make the issue occur
  • close all apps before sleep; no change.
  • logs show nothing on the bad resume (journalctl -b-1) with the last line showing sleep (no resume info)
  • hard freeze occurs about 3-5secs after resume. just long enough to type password in and get into desktop if i’m quick, but will freeze on the lockscreen if i dont do anything.
  • nvme’s swapped out with fresh installs. Currently using a WD SN770, but also tried 970evo, and some generic sk hynix/kioxia modules.
  • CapsLock is unresponsive (LED doesnt even toggle)
  • changed to Deep sleep, from s2idle; no change

Currently i’m using Fedora40 KDE with no tweaks as feature-wise, it all appears to work and there’s nothing specific in the framework installation notes that’s required like previous versions for brightness, PanelSelfRefresh (PSR) etc

I’m really pulling my hair out with this, and i’d rather use KDE if i can so has anyone experienced this and found a solution?

My advice would be to use sysrq to check if it gives you a hint on what goes wrong.
Check out: Linux Magic System Request Key Hacks — The Linux Kernel documentation

You can also try this. It solves a myriad of hardware-related problems.

Hopefully get time to check that tonight.
You’d just reminded me about another thing i noticed during the freeze: Capslock LED isnt even toggling so interesting to see if SysRq will have any response since the keyboard seems dead too.

took 15 mins over lunch to take a look at SysRq to get familiar with using it before it freezes again.

I’m completely new to the tool, so simply hitting alt+printScr(SysRq)+C seems to result in the same behaviour; hard freeze with caplock also failing to toggle LED. Nothing gets sent to console either (journalctl -f). had to force turn off the laptop to recover.

sysRq+T & M both return info as expected.

You need to be on the console - so if you were in a wayland session before, make sure to go down to the console with Ctrl-Alt-F3 or so. Then you can apply these.
That should work anytime. Just be careful to not sync and reboot by mistake :wink: Happens…
try out Alt-(FN+PRTSCR)+h for instance. At least on my FW16 that’s what I need to press.
Update: Does not work on mine. Will test. So used to it working I did not even test it.

Last but no least configuration you can do - I did that a l long time ago - was to configure syslog to dump all logs to the console → usually F8. That way, all I had to do was switch over to Ctrl-Alt-F8 and I had all kernel/app messages there.
Simply add :

GRUB_CMDLINE_LINUX="console=tty8 ignore_loglevel"

to your grub config, update-grub and on the nexg boot you should have all kernel message under Ctrl-F8.

still in testing so this isnt a real freeze, but the same behaviour occurs on console as terminal did; alt+sysrq+c will result in the hard freeze with same symptoms.
no capslock toggle, and even alt+sysrq+reisub is unresponsive.

fwiw no KDE user is logged on, fresh OS boot and i went straight into console.
laptop is on charge only; no dock/peripherals connected.

based on the symptoms, then i doubt this will work on a real hard freeze either since the keyboard is in a dead state too.

in that case, redirect all to the F8 console and check it when it happens

to be honest, on my FW16/AM - I don’t hibrenate, but all the rest works out of the boxSuspend & Co. and power usage is quite low.

dont think i’ll be able to switch to the F8 console as keyboard is unresponsive. i’ll try though when it next occurs (24-48hours hopefully).

I got curious to if a clean install would fail a sysrq+c, so swapped NVME to a 970evoPlus drive installed F40 gnome - same hard freeze with the alt+sysrq+c command which cant swap to the F8 output.

…Back to my KDE install…

My daughter us runnign KDE Neon + HWE kernels on her’s (FW 13) and so far has no problems.
Stopped using fedora a long time ago :}

I don’t think you mentioned what kind of sleep you’re using. I found that my Gen12 sometimes crashes coming out of s2idle sleep, but works reliably when using deep sleep.

yeah, i missed it (now added!) in OP.
that was the white flag moment where i gave up and came to post here; moved to deep sleep and it was still hard-freezing.

shortly after my last response, i went with reinstalling F40 KDE on a 970evo+ nvme. so far, not a single problem with it.

I’ve also found the odd report that could be similar to my issue related to the WD SN770 drive (one on amazon reviews, the other in a linux kernel bug thread).

8 days later, it seems solved!

1 Like

well, looks like no fix.

been using the 970evo+ nvme on both the F40 KDEspin and F40gnome - still with the random hard freeze immediately/within ~10secs after resume.

logs are no good - either nothing useful, or laptop wont respond.

# journalctl -b-1 -e
Jun 01 22:11:54 fedora chronyd[1424]: Can't synchronise: no selectable sources
Jun 01 22:11:54 fedora chronyd[1424]: Source 185.57.191.229 offline
Jun 01 22:11:54 fedora NetworkManager[1499]: <info>  [1717276314.4899] device (wlp166s0): set-hw-addr: reset MAC address to 8C:F8:C5:ED:F6:34 (unmanage)
Jun 01 22:11:54 fedora wpa_supplicant[1565]: p2p-dev-wlp166s: CTRL-EVENT-DSCP-POLICY clear_all
Jun 01 22:11:54 fedora wpa_supplicant[1565]: p2p-dev-wlp166s: CTRL-EVENT-DSCP-POLICY clear_all
Jun 01 22:11:54 fedora wpa_supplicant[1565]: nl80211: deinit ifname=p2p-dev-wlp166s disabled_11b_rates=0
Jun 01 22:11:54 fedora systemd[1]: Reached target sleep.target - Sleep.
Jun 01 22:11:54 fedora systemd[1]: Starting systemd-suspend.service - System Suspend...
Jun 01 22:11:54 fedora systemd-sleep[8131]: Performing sleep operation 'suspend'...
Jun 01 22:11:54 fedora kernel: PM: suspend entry (s2idle)
Jun 01 22:11:54 fedora wpa_supplicant[1565]: wlp166s0: CTRL-EVENT-DSCP-POLICY clear_all
Jun 01 22:11:54 fedora wpa_supplicant[1565]: wlp166s0: CTRL-EVENT-DSCP-POLICY clear_all
Jun 01 22:11:54 fedora wpa_supplicant[1565]: nl80211: deinit ifname=wlp166s0 disabled_11b_rates=0
Jun 01 22:11:54 fedora kernel: Filesystems sync: 0.036 seconds
Jun 02 09:06:54 fedora kernel: Freezing user space processes
Jun 02 09:06:54 fedora kernel: Freezing user space processes completed (elapsed 0.002 seconds)
Jun 02 09:06:54 fedora kernel: OOM killer disabled.
Jun 02 09:06:54 fedora kernel: Freezing remaining freezable tasks
Jun 02 09:06:54 fedora kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Jun 02 09:06:54 fedora kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jun 02 09:06:54 fedora kernel: PM: suspend devices took 0.226 seconds
Jun 02 09:06:54 fedora kernel: ACPI: EC: interrupt blocked
Jun 02 09:06:54 fedora gnome-shell[2643]: Failed to make thread 'KMS thread' normally scheduled: Operation not permitted

going to start to pull hardware out next.
removed 3 of the 4 modules; 2x USB-C & 1x HDMI module (1x USB-C remains for charging via dock PD).
RAM is next if crashes continue, even if memtest86 returns ok on multiple runs.