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.