I did the bisect to when this started happening. So here the deal:
SYMPTOMS:
3.x -> 3.3.8: All working!
3.4-rc1: rebooted automatically while resuming from suspension
3.4-rc2 -> 3.8-rc2: behavior described in this report
* Change on 3.3 that caused the system to reboot while trying to resume from first suspension:
b74f05d61b73af584d0c39121980171389ecfaaa is the first bad commit
commit b74f05d61b73af584d0c39121980171389ecfaaa
Author: Marcelo Tosatti <email address hidden>
Date: Mon Feb 13 11:07:27 2012 -0200
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_clock_state functions and use
restore_state to write to KVM_SYSTEM_TIME MSR, forcing an update.
Also move restore_sched_clock_state before __restore_processor_state,
since the later calls CONFIG_LOCK_STAT's lockstat_clock (also for TSC).
Thanks to Igor Mammedov for tracking it down.
Fixes suspend-to-disk with kvmclock.
Reviewed-by: Thomas Gleixner <email address hidden>
Signed-off-by: Marcelo Tosatti <email address hidden>
Signed-off-by: Avi Kivity <email address hidden>
:040000 040000 bdfcaa091fd3788bbe86a68ea61f0e792dfd3406 121a7fe2c66294dd13423ce556a74125980b6531 M arch
* Change that fixed the reboot issue on resume from first suspension but still caused a full lock when resuming from *second* suspend:
6742259866d03d5bc19815441ba928e8378343dc . This merge has a parent ( dba69d1092e291e257fb5673a3ad0e4c87878ebc ) that specifically states that aims to fix an issue cased by "s2ram broke due to this KVM commit: b74f05d61b73 x86: kvmclock: abstract save/restore sched_clock_state"
I can try to analyze the difference between this 2 commits but I think this is now way beyond my knowledge. What's the next steps?
I did the bisect to when this started happening. So here the deal:
SYMPTOMS:
3.x -> 3.3.8: All working!
3.4-rc1: rebooted automatically while resuming from suspension
3.4-rc2 -> 3.8-rc2: behavior described in this report
* Change on 3.3 that caused the system to reboot while trying to resume from first suspension:
b74f05d61b73af5 84d0c3912198017 1389ecfaaa is the first bad commit 84d0c3912198017 1389ecfaaa
commit b74f05d61b73af5
Author: Marcelo Tosatti <email address hidden>
Date: Mon Feb 13 11:07:27 2012 -0200
x86: kvmclock: abstract save/restore sched_clock_state
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_clock_state functions and use
restore_state to write to KVM_SYSTEM_TIME MSR, forcing an update.
Also move restore_ sched_clock_ state before __restore_ processor_ state,
since the later calls CONFIG_LOCK_STAT's lockstat_clock (also for TSC).
Thanks to Igor Mammedov for tracking it down.
Fixes suspend-to-disk with kvmclock.
Reviewed-by: Thomas Gleixner <email address hidden>
Signed-off-by: Marcelo Tosatti <email address hidden>
Signed-off-by: Avi Kivity <email address hidden>
:040000 040000 bdfcaa091fd3788 bbe86a68ea61f0e 792dfd3406 121a7fe2c66294d d13423ce556a741 25980b6531 M arch
* Change that fixed the reboot issue on resume from first suspension but still caused a full lock when resuming from *second* suspend:
6742259866d03d5 bc19815441ba928 e8378343dc . This merge has a parent ( dba69d1092e291e 257fb5673a3ad0e 4c87878ebc ) that specifically states that aims to fix an issue cased by "s2ram broke due to this KVM commit: b74f05d61b73 x86: kvmclock: abstract save/restore sched_clock_state"
I can try to analyze the difference between this 2 commits but I think this is now way beyond my knowledge. What's the next steps?