Hi Sudeep,
I had to pick on this thread since it is the subject I would like to address.
On 28/07/2023 12:48, Sudeep Holla wrote:
On Thu, Jul 27, 2023 at 03:15:46PM +0000, Salil Mehta wrote:
Hmm. I would have thought the keyboard etc. should contribute to those interrupts by default (isn't it?) or do we need to explicitly configure the devices for their interrupts to be use in wakeup from s2idle?
Hmm, when you say keyboard here, do you mean the serial console or does QEMU emulate a keyboard device ? If latter, then yes but better to check if the device is configured as wakeup source, the keyboard/pad DT node must have the "wakeup-source" property. If former, try if no_console_suspend in the cmdline(or something similar) helps. Again need to check if it is enabled as wakeup source.(HINT: check /sys/class/wakeup/wakeup*/device/power/wakeup)
Typically I use RTC on systems as I need not physical access to the platform to test that. $echo +20 > /sys/class/rtc/rtc0/wakealarm $ echo mem > /sys/power/state
This might not work as after putting the VM into s2idle state VM kind of hangs and becomes unresponsive. I would assume that keyboard interrupts are not being considered for waking-up the VM here either.
What are the keyboards you are referring here ? Just serial port input or emulated keyboards ?
I can see RTC is configured by Qemu/VMM during init.
Good, Jean-Philippe confirms atleast RTC is working in QEMU as wakeup source.
Not sure if RTC is available on your system/VM. You just need to find a working wakeup source for your experiment.
Sorry if you have already tried that and seeing issues. You may have just missed to list it here. Thought I will check. The timer are also disabled during any system level sleeps and hence can't wake up without a valid working wakeup source unlike the normal CPU sleep/idle states.
So something like "system_wakeup" from qemu prompt seems to be the way but It looks this is not enabled in Qemu due to missing ACPI handling. Need to dig this further.
Yes ACPI is a different story. Not sure if you have RTC driver support for ACPI, need to check.
Also make sure all the drivers have working suspend resume routines, sometimes the driver resume fails and if the console is not yet resumed at that point, you get no logs.
Good point. This could be a possibility.
Let me know if you need any help.
I have the following wakeup sources available on the guest:
PNP0C0E:00 PNP0C0C:00 rtc-efi.0 alarmtimer.0.auto
Being able to successfully put the guest to sleep by the interaction of PNP0C0E although the guest couldn't wakeup through the mean of rtc.
That seems related to the timestamp echoed into /sys/class/rtc/rtc0/wakealarm. If it is more than the curret "date '+%s'" a message of write status of 3 and write error is thrown.
I was thinking the wakealarm value would be the timestamp in the future for wakeup. Did I took a wrong assumption?
Any help/direction would be much appreciated.
Thanks in advance.
Regards, Miguel