CONFIG_PM_TRACE corrupts RTC

CONFIG_PM_TRACE corrupts RTC

[Andrew Morton]

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.

Re: CONFIG_PM_TRACE corrupts RTC

[Linus Torvalds]

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

Re: CONFIG_PM_TRACE corrupts RTC

[Andrew Morton]

On Mon, 26 Jun 2006 08:52:57 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

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

Oh, I thought it found some spare space in there somehow.

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

Re: CONFIG_PM_TRACE corrupts RTC

[Linus Torvalds]

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

Re: CONFIG_PM_TRACE corrupts RTC

[Pavel Machek]

On Mon 2006-06-26 09:30:49, Linus Torvalds wrote:
> 
> 
> 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.

This should probably be hidden in kernel debugging submenu... or
perhaps even out of the config system. It is only useful if you hack
the .c code, anyway, no?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html