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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
