From c7f66bc8a8549a9259e35196ced66f0382e54786 Mon Sep 17 00:00:00 2001 From: Frans Pop Date: Wed, 15 Oct 2008 22:01:21 -0700 Subject: [PATCH] --- yaml --- r: 114698 b: refs/heads/master c: b25f29b0da23f4f784f9bcae954b157e1f45cc69 h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/Documentation/power/s2ram.txt | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index cc00973a1584..f1c9a99d00ff 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 1bfcf1304ea79c46efc3724e548b13b4b442b418 +refs/heads/master: b25f29b0da23f4f784f9bcae954b157e1f45cc69 diff --git a/trunk/Documentation/power/s2ram.txt b/trunk/Documentation/power/s2ram.txt index b05f512130ea..2ebdc6091ce1 100644 --- a/trunk/Documentation/power/s2ram.txt +++ b/trunk/Documentation/power/s2ram.txt @@ -54,3 +54,21 @@ used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out that "radeonfb" simply cannot resume that device - it tries to set the PLL's, and it just _hangs_. Using the regular VGA console and letting X resume it instead works fine. + +NOTE +==== +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 mumber 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. + +As the clock keeps ticking it is also essential that the reboot is done +quickly after the resume failure. The trace option does not use the seconds +or the low order bits of the minutes of the RTC, but a too long delay will +corrupt the magic value.