linux-kernel - Re: pm_trace displays the wrong time from the RTC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070731151623.acff17ea.randy.dunlap@oracle.com>
Date:	Tue, 31 Jul 2007 15:16:23 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Dave Jones <davej@...hat.com>
Cc:	Chuck Ebbert <cebbert@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: pm_trace displays the wrong time from the RTC

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/