https://bugzilla.novell.com/show_bug.cgi?id=223365 ro@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ro@novell.com |mkoenig@novell.com ------- Comment #1 from ro@novell.com 2006-11-23 16:06 MST ------- -> util-linux maintainer -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=223365 mkoenig@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |suse@staerk.de ------- Comment #2 from mkoenig@novell.com 2006-12-13 09:28 MST ------- I need more information on this. Do you have your hardware clock set to localtime or UTC? What does "runs mad" mean exactly? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=223365 bj@sernet.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |werner@novell.com ------- Comment #4 from bj@sernet.de 2007-04-20 06:29 MST ------- see also a adjtime related bugreport #119909. hwclock's adjtime mechanism relies on the assumption that the hardware clock is never rappidly changed for whatever reason. As soon as the hardware clock is reset (for example cmos reset due to old battery) /etc/adjtime contains huge adjustments values after next boot time because 1. hwclock does a huge adjustment because it thinks the last time it adjusted the clock is VERY long ago, then 2. clock will be adjusted (manually or by ntp) and at next shutdown hwclock will see a huge discrepance between system and cmos clock and write a huge cmos clock deviation factor into adjtime. Then the time will be screewed every time the system is booted as long as adjtime is being removed. I saw those effects many times since years. So nifty the adjtime mechanism of hwclock is, so vulnerable it is. For that reason I would propose to NOT use adjtime mechanism by default. That might be done by simply removing /etc/adjtime before calling hwclock --systohc. Disabing systohc by setting SYSTOHC to no is not a real option. Most people will be happy with using systohc but without using the adjtime correction. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=223365 ------- Comment #6 from bj@sernet.de 2007-04-23 03:30 MST ------- Werner: do you basically disagree with anything I wrote in comnent #4 ? I think the reason why SYSTOHC=no is not good should be clear: When the (system-) time is being corrected it will have to be corrected after each reboot again. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=223365 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=223365#c8 Dr. Werner Fink <werner@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #8 from Dr. Werner Fink <werner@novell.com> 2007-12-12 09:31:46 MST --- For next realease the adjust file is only used for UTC within CMOS time as hwclock seems to miss the time zone information. For SYSTOHC=no only on boot the system time is read from CMOS because this is required to have a valid system time (+/- daylight saving offset). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.