Description of problem: In FC5, ntpd dosen't write system clock into hardware clock. Until FC4, hardware clock was automaticaly synchronized with system clock if ntpd was running. Version-Release number of selected component (if applicable): Both ntp-4.2.0.a.20050816-11 and ntp-4.2.0.a.20050816-11.FC5, both kernel-2.6.15-1.2054_FC5 and kernel-2.6.16-1.2111_FC5 shows this problem. How reproducible: always Steps to Reproduce: 1. service ntpd stop 2. hwclock --set --date="00:00" 3. service ntpd start 4. watch "date;hwclock --show" Actual results: hardware clock isn't synchronized with system clock. Expected results: hardware clock is synchronized with system clock after ntpd to start. and synchronized every 11 minute. Additional info: "adjtimex --print" shows "status" value "1". # adjtimex --print mode: 0 offset: 104 frequency: -6602025 maxerror: 91856 esterror: 591 status: 1 time_constant: 2 precision: 1 tolerance: 33554432 tick: 10000 raw time: 1147418571s 762220us = 1147418571.762220 ntpd logged messages "kernel time sync enabled". May 12 16:12:19 myhost ntpd[3024]: kernel time sync enabled 0001
A added few printk to kernel source and it looks like the notify_arch_cmos_timer function in arch/i386/kernel/time.c isn't called. It worked when I put a printk to the weak notify_arch_cmos_timer in kernel/time.c. Maybe something don't like the empty weak function?
If in kernel/time.c void __attribute__ ((weak)) notify_arch_cmos_timer(void) { return; } is changed to extern void __attribute__((weak)) notify_arch_cmos_timer(void); it is working. Compiled with gcc 3.4.5 working without changes. Maybe GCC 4.1.0 (Fedora) related ?
2.6.17-1.2138_FC5 shows same problem.
Today's rawhide, 2.6.17-1.2358.fc6PAE fixed this problem. Now, hardware clock is periodically synchronized to system clock again.
Although I expected it will fix this problem with new upstream version, today's update for FC5, 2.6.18-1.2189.fc5 shows same problem.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
This new kernel-2.6.18-1.2200.fc5 shows same problem. But I think it can be closed with NEXTRELEASE or RAWHIDE, because it, - dosen't occur in current rawhide/FC6-pre. - is not likely to be fixed in FC5; it seems a compiler-related problem. - is a minor problem; The Hardware clock was synced by script when ntpd stop.
As the FC6 kernel is 99% the same as this one, and differs in areas that would be extremely unlikely to affect this, it does sound like the problem is elsewhere. Jakub, is there any known breakage in the weak symbol handling in fc5's compiler?
Yes, there was a GCC bug, see http://gcc.gnu.org/PR27781 for details. There is a trivial workaround though, just add asm volatile (""); into the dummy weak function: void __attribute__ ((weak)) notify_arch_cmos_timer(void) { /* Workaround http://gcc.gnu.org/PR27781 */ asm volatile (""); return; } (or define the function in a different file, but that's much bigger change). Next FC5 GCC update will fix that, but I'm not sure when I want to release it yet, can take several weeks.
Great thanks. I'll add a patch to the next FC5 kernel update working around this.
Finally, I confirmed kernel-2.6.18-1.2224.fc5 fix this problem. Very thanks!
should be fixed in 2.6.18-1.2239.fc5 now in updates.