From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: CONFIG_PM_TRACE corrupts RTC
Date: Mon, 26 Jun 2006 15:53:35 UTC
Message-ID: <fa.JmXOID6UmACyR4xQI807hK13AB4@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0606260851000.3747@g5.osdl.org>

On Sun, 25 Jun 2006, Andrew Morton wrote:
>
> On a Sony Vaio, after a suspend-to-disk and a resume, `hwclock' says
>
>   The Hardware Clock registers contain values that are either invalid
>   (e.g.  50th day of month) or beyond the range we can handle (e.g.  Year
>   2095).
>
> and after a reboot the machine takes a trip back to 1969.  Setting
> CONFIG_PM_TRACE=n prevents this.

That's how it works. It's by design. The RTC is where the trace events are
stored, since that's the only piece of hw that reliably survives a reboot.

The help-text says:

        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).

Heh.

		Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: CONFIG_PM_TRACE corrupts RTC
Date: Mon, 26 Jun 2006 16:31:17 UTC
Message-ID: <fa.GSxBHLml5ZEFZMO/edyaBeFMiZY@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0606260927130.3747@g5.osdl.org>

On Mon, 26 Jun 2006, Andrew Morton wrote:
>
> Oh, I thought it found some spare space in there somehow.

I really tried. The fact is, the RTC chips have at least 114 bytes of
NVRAM available in them, and most have more. Sadly, while from a hw
standpoint it's non-volatile, the firmware I was testing with cleared it
all (including the extended banks etc).

> Making it `default y' was a bit unfriendly.  How's about `default n' and
> `depends on EMBEDDED'?

We can certainly make it 'default n', and perhaps hide it behind
EXPERIMENTAL (it's not really, but hey..). Not EMBEDDED, though, this is
literally meant to help random people who have a dead machine on suspend
be able to just turn this on, test suspend, and then when suspend causes a
dead machine, just turn off power and reboot immediately again, and it
will tell you which device was the last one to go through the resume
cycle.

		Linus