Updated Kernel Kills Suspend
Slackware 14.2 received a 4.4.115 kernel update related to the recent Spectre uproar. The update resolved the regression with not detecting the Ethernet cable status with the e1000e kernel module. The Slackware updates also included new gcc packages with the new retpoline protections.
After updating I discovered a new regression.
I attempted to suspend the Thinkpad T400 using
Fn+F4 and closing the lid. Nothing.
Digging into the logs revealed the suspend was puking at line 301 in
echo -n "mem" > /sys/power/state
echo: write error: Resource temporarily unavailable
Directly executing the command in a terminal resulted in the same error.
644 with the contents of
freeze mem disk.
Suspend worked fine when booting with 4.4.111 and 4.4.88, the previous Slackware 14.2 kernels.
pm-utils against the new kernel and new gcc did not help. Compiling
acpid 2.0.28 did not help.
I compiled a 4.4.113 and 4.4.114 kernel using the new gcc. Suspend worked fine with both. The regression appears in 4.4.115.
I tested suspend with 4.4.115 on the office desktop (Quad core Intel Core i5-6400) and living room media player (Intel Celeron 1037U). Same results.
At that point the circumstantial indications were I had something configured oddly that the patched 4.4.115 did not like.
Some earnest digging revealed the culprit to be
/etc/rc.d/rc.alsa-oss. That init script loads three modules:
modprobe -q -b snd-pcm-oss modprobe -q -b snd-seq-oss modprobe -q -b snd-mixer-oss
After disabling the script and rebooting, suspend again worked.
I had the file
chmod +x. Browsing my backups I discovered I enabled the script somewhere between March 15 and March 19, 2017. Not quite a year ago. The script contains comments that enabling is discouraged unless explicitly necessary. Likely I was experimenting and then forgot to disable the script. Still, enabling the script never caused any known errors until updating to the 4.4.115 kernel.
Interestingly, I could suspend multiple times, then manually execute
rc.alsa-oss and boom, that blocked the suspend.
The specific problem child seems to be the
snd-seq-oss module. After executing the script I could manually
rmmod the other two modules. I was unable to remove the snd-seq-oss module. I suspect the inability to remove the module is why the suspend timed out and failed.
I have no idea of the actual reason why the module blocks suspend.
Software has become far too complex. Updating software, free/libre or proprietary, almost always breaks something. Does this ever end?