Bug 191458 - FC5 ntpd dosen't write system clock into hardware clock
FC5 ntpd dosen't write system clock into hardware clock
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-05-12 03:19 EDT by Kazutoshi Morioka
Modified: 2015-01-04 17:27 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-12 00:50:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kazutoshi Morioka 2006-05-12 03:19:16 EDT
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:

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
Comment 1 Miroslav Lichvar 2006-05-18 09:49:14 EDT
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?
Comment 2 Milan Broz 2006-05-18 12:49:44 EDT
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 ?
Comment 3 Kazutoshi Morioka 2006-06-21 02:09:27 EDT
2.6.17-1.2138_FC5 shows same problem.
Comment 4 Kazutoshi Morioka 2006-07-07 22:36:50 EDT
Today's rawhide, 2.6.17-1.2358.fc6PAE fixed this problem.
Now, hardware clock is periodically synchronized to system clock again.
Comment 5 Kazutoshi Morioka 2006-09-25 19:52:12 EDT
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.
Comment 6 Dave Jones 2006-10-16 20:38:24 EDT
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.
Comment 7 Kazutoshi Morioka 2006-10-16 22:25:19 EDT
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.
Comment 8 Dave Jones 2006-10-17 01:41:53 EDT
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?
Comment 9 Jakub Jelinek 2006-10-17 02:53:04 EDT
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 ("");

(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.
Comment 10 Dave Jones 2006-10-17 18:44:32 EDT
Great thanks. I'll add a patch to the next FC5 kernel update working around this.
Comment 11 Kazutoshi Morioka 2006-11-04 03:14:32 EST
Finally, I confirmed kernel-2.6.18-1.2224.fc5 fix this problem.
Very thanks!
Comment 12 Dave Jones 2006-11-12 00:50:50 EST
should be fixed in 2.6.18-1.2239.fc5 now in updates.

Note You need to log in before you can comment on or make changes to this bug.