Re: 2.6.18-rc4 (and earlier): CMOS clock corruption during suspend to disk on i386

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Thursday 10 August 2006 02:12, Pavel Machek wrote:
> > > > > > It looks like the CMOS clock gets corrupted during the suspend to disk
> > > > > > on i386.  I've observed this on 2 different boxes.  Moreover, one of them is
> > > > > > AMD64-based and the x86_64 kernel doesn't have this problem on it.
> > > > > > 
> > > > > > Also, I've done some tests that indicate the corruption doesn't occur before
> > > > > > saving the suspend image.  It rather happens when the box is powered off
> > > > > > or rebooted (tested both cases).
> > > > > > 
> > > > > > Unfortunately, I have no more time to debug it further right now.
> > > > > 
> > > > > Do you have Linus' "please corrupt my cmos for debuggin" hack enabled?
> > > > 
> > > > Well, I know nothing about that. ;-)
> > > 
> > > CONFIG_PM_TRACE=y will scrog your CMOS clock each time you suspend.
> > 
> > Oh dear.  Of course it's set in my .config.  Thanks a lot for this hint. :-)
> > 
> > BTW, it's a dangerous setting, because some drivers get mad if the time after
> > the resume appears to be earlier than the time before the suspend.  Also the
> > timer .suspend/.resume routines aren't prepared for that.
> 
> Its config option should just go away. People comfortable using *that*
> should just edit some header file. Rafael, could you do patch doing
> something like that?

Just remove the option from Kconfig or the whole setting?

Shouldn't we also change the timer .resume() routines to check if the time
after the resume is later than (or at least the same as) the time before the
suspend and set the "sleep length" to 0 if not?

Rafael