lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANcMJZCuYmim8q5ZPg2ppwA8T0jXMmpGowikeca5EzaoeVxr-Q@mail.gmail.com>
Date:	Mon, 17 Jun 2013 19:14:07 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Shuah Khan <shuah.kh@...sung.com>
Cc:	"rjw@...k.pl" <rjw@...k.pl>,
	"a.zummo@...ertech.it" <a.zummo@...ertech.it>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>
Subject: Re: pm: System date and time set incorrectly after suspend/resume to disk

On Mon, Jun 17, 2013 at 6:30 PM, Shuah Khan <shuah.kh@...sung.com> wrote:
> I am seeing a problem on my system after a suspend to disk in reboot or
> shutdown mode. When pm_trace is 0 (which is the default), I can't
> reproduce the problem easily. I have to run a few more suspend tests
> before I see the problem. When pm_trace is disabled, the problem showed
> up when I ran suspend in platform mode in a row. However when pm_ptrace
> is enabled, problem happens on the very first spend to disk in reboot mode.
>
> Steps to run into the issue:
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo reboot > disk
> echo disk > state
>
> or
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo shutdown > disk
> echo disk > state
>
> When system comes back up, system time set to incorrect time.

So I this is by design. Please see Documentation/power/s2ram.txt for details:

"pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
Reason for this is that the RTC is the only reliably available piece of
hardware during resume operations where a value can be set that will
survive a reboot.

Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option."

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ