Re: pm_trace displays the wrong time from the RTC

From: Randy Dunlap
Date: Tue Jul 31 2007 - 18:11:39 EST


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 ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/