I have a long habit of building my own kernels (from time to time), using the stock sources with just the ConKolivas patches, -O3 instead of -O2 optimisation where I can set it, and targetting the Core2 CPU family. The config was based initially on one of the latest kernels provided by Ubuntu 14.04; basically the only things I deactivated in there were the settings related to AppArmor, SELinux and family.

The latest kernel I built a few years ago was 4.14.23 . It works fine, with long uptimes on a laptop that's suspended at least once per day, but occasionally the suspend procedure will remain stuck, the power LED remains on, and I need to power-cycle the machine. The exact symptoms reported countless times already.

This week I upgraded to 4.19.133 (which was the current version when I started the build and rigorous testing). I finally upgraded my main install think I had tested everything, only to find out that the suspend issue hits systematically.

The slightly older 4.19.0-9 kernel from Devuan Beowulf (aka Debian Buster) is not affected, but annoyingly the config differences are too numerous to have hope of finding the key difference. I tried the same XHCI configuration in my kernel but that didn't help.

I haven't yet found any reports about suspend issues with this particular kernel version so I don't have high hopes that the current version (137) has a fix, but we'll see.

Can anyone provide me a real answer what could go wrong here and/or how I might prevent it? There is a youtube video about a fix for a 5.x kernel, I doubt it'd be of any use to me.

NB: my main system is still on Kubuntu 14.04, I'm setting up a 2nd system with Devuan Beowulf. Both systemd free, in other words.

  • As I feared, upgrading to 4,19.137 make no difference whatsoever.
    – RJVB
    Commented Aug 6, 2020 at 22:28

2 Answers 2


I just went from 4.19.0-9 to 4.19.0-10. My PC stopped waking correctly from suspend on the 4.19.0-10 kernel. I must use the power button to wake. Toggling reboots between the two, I can verify my suspend issues only occur with the 4.19.0-10 version. I have yet not found any real issues in the SYSLOG, although offhand it appears there are many more ACPI entries for a working system. Maybe this small version difference could help someone narrow down the issue.

  • Thanks. For those without easy access to this information: 4.19.0-9 corresponds to kernel version 4.19.118-2+deb10u1; 4.19.0-10 to 4.19.132-1. I don't know if that implies that the latter does NOT have any Debian patches applied?!
    – RJVB
    Commented Aug 7, 2020 at 10:03
  • I've done some testing with /sys/power/pm_test and s2ram as suggested at infradead.org/~mchehab/kernel_docs/power/… . Didn't teach me anything except that KMS is in use in both the succeeding and the failing situations. I'm just going to try to build the 4.19.0-9 kernel sources with my own patches and config on top of it, and see how that goes.
    – RJVB
    Commented Aug 7, 2020 at 11:00
  • So... I had to build several versions of the 4.19.118 kernel behind Debian's 4.19.0-9 because of their %$@#$ lockdown/"we MOK thee" patches that caused my ZFS and other kmods to be rejected because of a missing key. But: the ConKolivas and my 2 other patches applied cleanly (enough) and as a result I now have a recent Debian'ish kernel that can properly suspend all my computers.
    – RJVB
    Commented Aug 8, 2020 at 18:57

I think I just might have stumbled upon something of an answer, or at least a fix for kernels built with the Con Kolivas (ck1) patches - for the 5.7 kernel. It shouldn't call finish_cpu() when offlining a core. Given the symptoms I've seen that actually sounds like a very plausible explanation: if finish_cpu() does what I think it does that means the cpu in question can no longer do anything after calling that function (and I would expect that the firmware will do the equivalent operation when it's safe to do so).

Users of a -ck1 kernel can try to apply the commit muqss: Revert invocation of "finish_cpu" when offlining core. That does not actually revert a change made by the patch so maybe the patch will or can be made to apply to stock kernels too. It's extremely simple.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .