This seems to now be FIXED as of liquorix 4.11-15!!!
Back to top

Tried 4.11-16 here, and it still does the same thing to me (blank screen on resume, the PC doesn't respond to anything I press)
Back to top

Make sure your suspend script does:

/usr/sbin/pm-suspend

and NOT: echo mem >/sys/power/state
That's what first made a difference for me.
Back to top

That's actually a good point, for anyone still following this thread with suspend issues, how are all of you suspending?

On my laptops that are working, I stick with SystemD's logind. I'm not currently aware of what it depends on, but I suspect it does the "right" thing, better than what's in pm-utils or other packages. And this is without hitting a button or running a script, I just close the lid.

Here's some documentation here:

wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#systemd.
wiki.archlinux.org/index.php/Power_management#Power_management_with_systemd

SystemD is pretty universal so Arch's documentation is probably sufficient.
Back to top

I use a script b/c I do some other things with this laptop, such as check for dock / undock status change, eth / wifi switch, etc. I also failed to mention that I do not use systemd (Antix is a "nosystemd" / systemd-optional distro).
Back to top

It's not using pm-tools/pm-suspend as far as I'm aware.



My distro uses a custom program that runs the commands (much like Mate's: linuxscoop.com/wp-content/uploads/2014/12/Linux-Mint-17_1-MATE-Quit-Session.jpg) which is cbpp-exit: https://github.com/CBPP/cbpp-exit

It runs this command:



So I'm guessing it does shut down with logind...?
Back to top

I'm using KDE Neon but I don't know what the closing lid/suspend action is, is there an easy way to see?
Back to top

Just installed 4.12.0-8.1-liquorix-amd64 but still does the same thing for me.
Back to top

I also got the same results. On at least two systems, one a lenovo T420, one on an older AMD Abit motherboard.

With 4.11-07
Back to top

I can confirm that something odd is happening on v4.12 myself. When docking or unplugging power, the system becomes unresponsive.

I was able to figure out what was going on by changing the IO scheduler to kyber. Then, I left 'htop' running and found that a kworker steals all the CPU of a single core. Not exactly sure what is going on but I'll review the bfq mailing list and see if there's any known bugs to blk-mq / bfq-mq. That and make sure we refreshed MuQSS properly in zen-kernel.

Worst case, if blk-mq is the culprit, I'll revert back to the legacy block until suspend issues can be fixed.

EDIT: Yes, it's blk-mq. You can work around it for now by booting with "scsi_mod.use_blk_mq=0". I tested it on my work laptop and that fixes issues with switching from A/C to battery. I'll set the default to the legacy block framework unless there's already a fix available.
Back to top