2.6.18-rc4 (and earlier): CMOS clock corruption during suspend to disk on i386
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!
Quoted 10 lines
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_64kernel 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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 6 lines · Pavel Machek
Hi!
Quoted 5 lines
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_64kernel doesn't have this problem on it.
Quoted 7 lines
Quoted 5 lines
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
Quoted 11 lines · On Wed, 9 Aug 2006 22:01:42 +0200 "Rafael J. Wysocki" <[email protected]> wrote:
Quoted 10 lines · Pavel Machek
Hi!
Quoted 9 lines
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_64kernel 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).
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 14 lines · Andrew Morton
Quoted 11 lines · On Wed, 9 Aug 2006 22:01:42 +0200 "Rafael J. Wysocki" <[email protected]> wrote:
Quoted 10 lines · Pavel Machek
Hi!
Quoted 9 lines
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_64kernel 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).
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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=ywill 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!
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 11 lines
Quoted 9 lines
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_64kernel 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. ;-)
Quoted 7 lines
Quoted 1 line
CONFIG_PM_TRACE=ywill 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?
Signature · 1 line
Thanks for all the (sleeping) penguins.
Hi,
Quoted 18 lines · Pavel Machek
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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_64kernel 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).
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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=ywill scrog your CMOS clock each time you suspend.Oh dear. Of course it's set in my .config. Thanks a lot for this hint. :-)
Quoted 7 lines
Quoted 3 lines
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,
Quoted 27 lines · Rafael J. Wysocki
Quoted 18 lines · Pavel Machek
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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_64kernel 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).
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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=ywill scrog your CMOS clock each time you suspend.Oh dear. Of course it's set in my .config. Thanks a lot for this hint. :-)
Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines
Just remove the option from
Kconfigor 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
Quoted 11 lines · Rafael J. Wysocki
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
Quoted 1 line
CONFIG_PM_TRACE=ywill 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?
Quoted 9 lines · Jesse Brandeburg
Quoted 8 lines · Rafael J. Wysocki
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
CONFIG_PM_TRACE=ywill 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.
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 32 lines · Rafael J. Wysocki
Hi,
Quoted 29 lines · Rafael J. Wysocki
Quoted 18 lines · Pavel Machek
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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_64kernel 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).
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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=ywill scrog your CMOS clock each time you suspend.Oh dear. Of course it's set in my .config. Thanks a lot for this hint. :-)
Quoted 7 lines
Quoted 3 lines
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
Kconfigor the whole setting?
Quoted 7 lines
Quoted 3 lines
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
Kconfigand 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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 1 line · Pavel Machek
On Thu 2006-08-10 22:51:20, Rafael J. Wysocki wrote:
]--snip--[
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
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
Kconfigor 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?
Quoted 6 lines
Quoted 3 lines
Hm, I'm thinking it may actually be useful to have in
Kconfigand 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
Quoted 25 lines · Rafael J. Wysocki
Hi,
Quoted 22 lines · Pavel Machek
Quoted 21 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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_64kernel 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).
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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=ywill 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.
Quoted 5 lines
Quoted 3 lines
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
Kconfigor the whole setting?
Removing it from Kconfig should be enough.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 7 lines · Rafael J. Wysocki
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_64kernel 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
Quoted 10 lines · john stultz
Quoted 7 lines · Rafael J. Wysocki
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_64kernel 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
Quoted 6 lines · Rafael J. Wysocki
Quoted 5 lines · john stultz
Quoted 4 lines · Rafael J. Wysocki
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_64kernel doesn't have this problem on it.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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