Hi Thomas,
On 2016年07月19日 16:36, Thomas Gleixner wrote:
On Tue, 19 Jul 2016, Chen Yu wrote:
It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is actually no other process would like to grab
this lock on that problematic platform.
Further investigation shows that, the problem is caused by setting
/sys/power/pm_trace to 1 before the 1st hibernation, since once
pm_trace is enabled, the rtc becomes an unmeaningful value after resumed,
So why is the RTC value useless if pm_trace is enabled? I really have a hard
time to understand why pm_trace would affect the sleep time readout from RTC.
Thanks,
tglx
After pm_trace is enabled, during system suspend/hibernate, the hash name of
each devices will be written to rtc, so the rtc value depends on what
we write in last suspend
round, thus pm_trace can be used for diagnose which device failed to
suspend(eg, the suspending
on this device hang the system, we reboot the system , and check rtc
hash value).
In our case, after first hibernate/resume round, we found our current
system time
is at 2117, so syscore_resume -> timekeeping_resume :
__timekeeping_inject_sleeptime(tk, &ts_delta)
would inject a quite large delta : 2117 - 2017 year, thus the
sleep_time_bin is overflow.
thanks,
Yu
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html