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.