Kernel suspends too quickly, upon resume continues suspend tasks

After reviewing all the information I can find, I've come to the conclusion that you are affected by this kernel bug. which has affected numerous systems including Asus, Dell, HP, Lenovo, etc. This bug which will be marked for expiration in 47 days if no further activity occurs, is extremely hot, scoring 412 on the bug heat score and is reported as affecting 86 people at this moment. I recommend that you subscribe to it and provide any kernel related info that you can to help clarify the issue so that it remains open and the devs can squash it.

A likely workaround is upgrading/reverting to kernel 4.4.8 as noted here and confirmed here and here.

Work has been requested to reverse bisect the kernel but the bug is currently expired so it looks like the devs didn't get all the help they needed in determining the root cause of this behavior. Near as I can tell from perusing the bug report this problem appeared in kernel 4.4.0, was resolved in 4.4.8 and then reappeared sometime around 4.5.2 but I won't claim to be certain.

Another possible kernel upgrade workaround was reported here although I haven't found confirmation on that one.

If your using a kernel from the repository, it could be helpful if you were to launch ubuntu-bug linux from the terminal to create a new bug report providing specific information regarding your kernel/issue.

You might wish to rule out out-of-order-execution as a culprit as well. You should be able to accomplish this by disabling all but CPU0 like:

for x in /sys/devices/system/cpu/cpu*/online; do
  echo 0 >"$x"
done

You might also find this information useful in tracking down the root cause of this issue.

Sources:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574125/

https://unix.stackexchange.com/questions/145645/disabling-cpu-cores-on-quad-core-processor-on-linux

This is the specific problem that appears in dmesg:

PM: Preparing system for sleep (mem)
[...]
PM: Suspending system (mem)

Initially try to do:

sudo -H gedit /etc/default/grub

and set the line:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"

Other parameters that previously existed in this line can leave unchanged, i.e., only adding this sometimes indicated.

To make changes effective, run:

sudo update-grub

In addition there is the report of a problem with apt-daily.service, which is the update service runs at boot, which makes it all running indefinitely, unable to finish.

Try disable the service:

sudo apt-systemctl disable daily.service # disable run when system boot

Another workaround that worked reasonably to me:

sudo -H gedit /etc/systemd/system.conf

Change the following lines uncommenting and setting to a value that still permits the loading system:

# DefaultTimeoutStartSec = 90s
DefaultTimeoutStartSec = 10s
# DefaultTimeoutStopSec = 90s
DefaultTimeoutStopSec = 10s

Note the dmesg if the adjustment does not generate load failure and, if appropriate, adjust the value.

Regarding these comments:

"... Kernel partially suspends and powers down system but upon resume completes suspend with immediate wake (no visible problems other than in log)"

and

"Exact same scenario with 4.4.8 - Systemd suspends system and upon resume Kernel immediately sleeps and wakes up. No one would know this is happening unless they examine the logs I posted above."

This is not an actual problem and is purely a consequence of when the console output is being suspended and later resumed but it's certainly unnerving to see the buffered output produced during suspend actually coming out during the resume.

For debugging purposes, the console suspend can be disabled:

# echo N > /sys/module/printk/parameters/console_suspend
# cat /sys/module/printk/parameters/console_suspend
N

Then trigger the suspend. For example, by:

# echo mem > /sys/power/state

You should see all the suspend related console output come out prior to resume exactly as you'd expect.