Re: pm_trace displays the wrong time from the RTC

[Randy Dunlap <randy.dunlap@oracle.com>]

On Tue, 31 Jul 2007 17:56:09 -0400 Dave Jones wrote:

> On Tue, Jul 31, 2007 at 02:39:39PM -0700, Randy Dunlap wrote:
>  > On Tue, 31 Jul 2007 17:20:10 -0400 Chuck Ebbert wrote:
> 
>  > > include/asm-generic/rtc.h:
>  > > 102         /*
>  > > 103          * Account for differences between how the RTC uses the values
>  > > 104          * and how they are defined in a struct rtc_time;
>  > > 105          */
>  > > 106         if (time->tm_year <= 69)
>  > > 107                 time->tm_year += 100;
>  > > 108 
>  > > 109         time->tm_mon--;
>  > 
>  > 
>  > That's this config option (read all of it):
>  > 
>  > config PM_TRACE
>  > 	bool "Suspend/resume event tracing"
>  > 	depends on PM_DEBUG && X86 && EXPERIMENTAL
>  > 	default n
>  > 	---help---
>  > 	This enables some cheesy code to save the last PM event point in the
>  > 	RTC across reboots, so that you can debug a machine that just hangs
>  > 	during suspend (or more commonly, during resume).
>  > 
>  > 	To use this debugging feature you should attempt to suspend the machine,
>  > 	then reboot it, then run
>  > 
>  > 		dmesg -s 1000000 | grep 'hash matches'
>  > 
>  > 	CAUTION: this option will cause your machine's real-time clock to be
>  > 	set to an invalid time after a resume.
> 
> Doesn't this only take effect if you've been poking /sys/power/pm_trace though ?

Looks like only if /sys/power/pm_trace is enabled, yes.

> Also, look at the date in the output from Chuck. It looks like only the
> year is wrong.  I'd have expected more than just the century byte to have been
> corrupted.

and month, but the code snippet that he posted accounts for that also.

> That +100 heuristic seems really odd to me.  Possibly it needs to be
> checking if the century byte is set/unset, or it needs additional
> clamping to make sure it doesn't overflow.

OK, worth looking into...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***