This ongoing issue finally solved by Google’s Gemini AI. This has been a real head-scratcher for years. Nothing showed in the logs, and I was convinced it was a hardware issue, and even returned the computer to the shop several times. No “smoking gun” was ever found.
I managed to provide the clue that immediately led Gemini to the solution: The resets occurred with the Fedora distro, disappeared with the Garuda distro, and returned with the openSUSE distro.
Here is Gemini's response (after I provided my system details):
Why the Resets Stopped on Garuda
Garuda Linux uses a customized performance-tuned kernel (zen-kernel). By default, it changes the CPU governor and power management states to maximize performance. This prevents the processor from entering deep, ultra-low-voltage sleep states.
On openSUSE Leap and Fedora, standard enterprise power-saving modules are active. When your Intel CPU suddenly enters or leaves an ultra-low power state, the voltage drops too quickly. Your motherboard thinks it is a power failure and instantly reboots to protect the machine.
First off, why would you effectively disable power management with setting it to 1?
Secondly, is/was the power-profiles-daemon running?
I have three Dell systems here all running Gen 9.5 CPU’s (which is not shown in your output). The CPU’s in use here are i5-10500T and i7-8700 all are Hexa Core which now use the cpu frequency driver intel_cpufreq.
In my case I noticed that the cpu frequency was not stepping with the intel_pstate driver, so for switching this to occur and power-profile-daemon to function was adding intel_pstate=passive to the boot options. In passive mode it switches to intel_cpufreq.
I’ve not had any issues with my systems suspending, likewise waking up. My systems do use GNOME and Hyprland as well as Wayland, so maybe it’s also X11/Plasma related. The Hyprland setup doesn’t even have swap, the only thing for this setup is having to press the power button to bring it out of suspend…
One other discrepancy, there is now the update-bootloader command if wanting to use the command line, or Cockpit and the Bootloader plugin
I would suggest removing that option, check cpupower frequency-info if your using intel_pstate, set the option to passive, see if it switches to intel_cpufreq and make sure the power daemon is running. Then you can use the power settings to set performance if you want, or use balanced when not needing performance.
# cpupower frequency-info
analyzing CPU 7:
driver: intel_pstate
CPUs which run at the same hardware frequency: 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 4.70 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 4.70 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 800 MHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
Also, I keep an eye on temps. These are staying nice and calm:
In my bios there is a setting that implements a “dummy load” for this sort of thing in the power or miscellaneous section I believe and is usually caused by an older PSU reading the “deep sleep” state as a failure
