Linux almost stock 4.19.133 suspend fails, works fine with Devuan's 4.19.0-9 kernel

Question

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.

Answer 1

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.

Answer 2

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.