Hi,
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.
Greetings,
Rafael
Hi!
>
> 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?
:-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 2006-08-09 at 14:26 +0200, Rafael J. Wysocki 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).
Hmmm. Could you better describe the corruption you're seeing?
I've just gotten a report about uptime reporting odd values after resume
when the CMOS clock was set to the past during a suspend to disk, but
that's somewhat expected and I would think it would occur on x86_64 as
well.
thanks
-john
On Wednesday 09 August 2006 14:30, Pavel Machek wrote:
> Hi!
> >
> > 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. ;-)
Rafael
On Wednesday 09 August 2006 19:44, john stultz wrote:
> On Wed, 2006-08-09 at 14:26 +0200, Rafael J. Wysocki 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).
>
> Hmmm. Could you better describe the corruption you're seeing?
After I do "echo disk > /sys/power/state" and the system suspends, the
CMOS clock settings, as visible via the BIOS setup, are more or less random.
Rafael
On Wed, 9 Aug 2006 22:01:42 +0200
"Rafael J. Wysocki" <[email protected]> wrote:
> On Wednesday 09 August 2006 14:30, Pavel Machek wrote:
> > Hi!
> > >
> > > 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.
On Wed, 2006-08-09 at 22:04 +0200, Rafael J. Wysocki wrote:
> On Wednesday 09 August 2006 19:44, john stultz wrote:
> > On Wed, 2006-08-09 at 14:26 +0200, Rafael J. Wysocki 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).
> >
> > Hmmm. Could you better describe the corruption you're seeing?
>
> After I do "echo disk > /sys/power/state" and the system suspends, the
> CMOS clock settings, as visible via the BIOS setup, are more or less random.
And after resuming does time output the time/date properly, or is it
confused as well?
thanks
-john
On Wednesday 09 August 2006 22:12, Andrew Morton wrote:
> On Wed, 9 Aug 2006 22:01:42 +0200
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > On Wednesday 09 August 2006 14:30, Pavel Machek wrote:
> > > Hi!
> > > >
> > > > 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.
Hi!
> > > > > 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?
--
Thanks for all the (sleeping) penguins.
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
Hi,
On Thursday 10 August 2006 14:15, Rafael J. Wysocki wrote:
> 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?
Hm, I'm thinking it may actually be useful to have in Kconfig and if we change
the timer resume to detect the dangerous situation and prevent it from
happening, that should be sufficient.
Rafael
On 8/10/06, Rafael J. Wysocki <[email protected]> wrote:
> > > > > 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?
I've seen this problem too, thought it was only mm.
Should the problem go away if I disable CONFIG_PM_TRACE?
On Saturday 12 August 2006 21:08, Jesse Brandeburg wrote:
> On 8/10/06, Rafael J. Wysocki <[email protected]> wrote:
> > > > > > 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?
>
> I've seen this problem too, thought it was only mm.
> Should the problem go away if I disable CONFIG_PM_TRACE?
Yes.
On Thu 2006-08-10 14:15:21, Rafael J. Wysocki wrote:
> 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?
Removing it from Kconfig should be enough.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu 2006-08-10 22:51:20, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 10 August 2006 14:15, Rafael J. Wysocki wrote:
> > 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?
>
> Hm, I'm thinking it may actually be useful to have in Kconfig and if we change
> the timer resume to detect the dangerous situation and prevent it from
> happening, that should be sufficient.
Well, it is still too easy to shoot yourself in the foot. Your time
will be wrong if you enable innocent-sounding option.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Monday 14 August 2006 00:33, Pavel Machek wrote:
> On Thu 2006-08-10 22:51:20, Rafael J. Wysocki wrote:
]--snip--[
> > > > > 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?
> >
> > Hm, I'm thinking it may actually be useful to have in Kconfig and if we change
> > the timer resume to detect the dangerous situation and prevent it from
> > happening, that should be sufficient.
>
> Well, it is still too easy to shoot yourself in the foot. Your time
> will be wrong if you enable innocent-sounding option.
We can add DANGEROUS to it. :-)
Rafael