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 Aug 6 at 22:28

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.

| improve this answer | |
  • 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 Aug 7 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 Aug 7 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 Aug 8 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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.