qemu-guest-agent and pm-utils are both universe so adding a dependency or
better a recommends as that is what it correctly is is an option if that turns
out to help.
Independent to a fix of this issue (which we don't know yet if it is one) it
would also ensure that anything that plug into /usr/lib/pm-utils/sleep.d would
be correctly processed on in-guest suspend.
Checking kernel ram suspend in increasing test modes:
$ echo "freezer" | sudo tee /sys/power/pm_test
$ cat /sys/power/pm_test
$ echo "mem" | sudo tee /sys/power/state
$ sudo cat /sys/kernel/debug/suspend_stats
This iterates the stages:
1. freeze
/sys/kernel/debug/suspend_stats - success, no fails
dmesg:
[ 6591.187071] PM: Syncing filesystems ... done.
[ 6591.191328] PM: Preparing system for sleep (freeze)
[ 6591.196663] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 6591.197909] OOM killer disabled.
[ 6591.197912] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 6591.199096] suspend debug: Waiting for 5 second(s).
[ 6596.199897] PM: Finishing wakeup.
[ 6596.199901] OOM killer enabled.
[ 6596.199903] Restarting tasks ... done.
2. devices
/sys/kernel/debug/suspend_stats - success, no fails
dmesg:
As above plus this on wakeup:
[ 6714.731269] pciehp 0000:00:01.0:pcie004: Slot(0): Already enabled
[ 6714.731607] pciehp 0000:00:01.1:pcie004: Slot(0-1): Already enabled
[ 6714.731945] pciehp 0000:00:01.2:pcie004: Slot(0-2): Already enabled
[ 6714.732282] pciehp 0000:00:01.3:pcie004: Slot(0-3): Already enabled
[ 6714.761113] Suspended for 0.828 seconds
[ 6714.823542] PM: resume of devices complete after 92.743 msecs
3. platform
/sys/kernel/debug/suspend_stats - success, no fails
dmesg:
As above plus:
[ 6873.053837] PM: late suspend of devices complete after 0.546 msecs
[ 6873.079422] PM: noirq suspend of devices complete after 25.579 msecs
[ 6873.079426] suspend debug: Waiting for 5 second(s).
[ 6878.162582] PM: noirq resume of devices complete after 82.393 msecs
[ 6878.163888] PM: early resume of devices complete after 0.931 msecs
processors/core tests are not supported for suspend to idle.
So as far as testable all works.
Test the "real thing" => hangs just as much.
Doing the same via pm-utils looks just the same :-/
So by the tests this isn't any process or device freeze on the suspend.
Instead it is the "core" change of state into the sleep that breaks it.
This requires all sorts of acpi magic which might after all just not fully
apply to the (virtual) arm environment.
I enabled all kernel logs to be on the serial console, but see on that just
what I saw on the tests. All good until the effective
[ 435.748784] PM: suspend-to-idle
But on the other end this state isn't found
$ virsh qemu-monitor-command artful-uvt-test-agent --pretty
'{"execute":"query-status"}'
[...]
"status": "running",
I use guests I spawned with a template that explicitly adds acpi, which might
after all be wrong.
So I try modifying the features now hoping that the defaults are better than my
xml.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1737786
Title:
(arm64) unable to dompmwakeup a vm after being suspended
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1737786/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
