Bug 157581 - clock loses ticks, 6 seconds in 35 minutes (1:350)
clock loses ticks, 6 seconds in 35 minutes (1:350)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
bzcl34nup
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-12 16:10 EDT by John Reiser
Modified: 2010-12-05 02:19 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:19:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2005-05-12 16:10:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.7) Gecko/20050509 Fedora/1.0.3-5 Firefox/1.0.3

Description of problem:
The time reported by /bin/date loses 6 seconds over a period of 35 minutes, when compared to an external quartz clock.  This is on PowerPC Mac mini.  The same hardware under Mac OS X 10.3.9 keeps accurate time (no loss, no gain over 23 minutes elapsed.)  The FC4test3 system ("Workstation" install) was "idle": running "vmstat 15" for the life of the test showed only the occasional bupdate, and no cron jobs (prelink, slocate, etc.).  Screensaver was "blank" only.

Version-Release number of selected component (if applicable):
kernel-devel-2.6.11-1.1290_FC4

How reproducible:
Always

Steps to Reproduce:
1. run /bin/date, compare output to external clock.
2. wait half an hour.
3. run /bin/date, compare output to external clock.  Compare indicated elapsed times from step 1.
  

Actual Results:  The time from /bin/date loses 6 seconds over 35 minutes.

Expected Results:  The time delta from /bin/date should match the time delta of the [accurate] external clock.

Additional info:
Comment 1 John Reiser 2005-05-12 16:11:40 EDT
This bears a passing resemblance to bug #127411, but the hardware is
significantly different (Mac instead of PC) and the kernel versions are at least
6 months apart.
Comment 2 John Reiser 2005-05-12 18:11:06 EDT
Even booting just to single user mode [boot: 2.6.11-1.1290_F single], /bin/date
loses 4 seconds in 23 minutes.  So X11 is not the problem.  "ps ax" shows:
-----
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:02 init [S]
    2 ?        SN     0:00 [ksoftirqd/0]
    3 ?        S<     0:00 [events/0]
    4 ?        S<     0:00 [khelper]
    5 ?        S<     0:00 [kthread]
   26 ?        S<     0:00 [kblockd/0]
   68 ?        S      0:00 [pdflush]
   69 ?        S      0:00 [pdflush]
   71 ?        S<     0:00 [aio/0]
   70 ?        S      0:00 [kswapd0]
   30 ?        S      0:00 [khubd]
  155 ?        S      0:00 [kseriod]
  318 ?        S      0:00 [kjournald]
  944 ?        Ss     0:00 kmodule -d
  952 ?        S<s    0:00 udevd
 1358 ?        S      0:00 [khpsbpkt]
 1388 ?        S      0:00 [knodemgrd_0]
 1630 tty1     Ss     0:00 init [S]
 1631 tty1     S      0:00 /bin/sh -l
 1668 tty1     R+     0:00 ps ax
$ 
-----
Comment 3 Colin Charles 2005-05-17 18:58:51 EDT
Its hard to say 6s in 35 minutes, but I left the Mac Mini turned on all night,
and notice a skewage of about 2 minutes or so. So I can safely reproduce this
using FC4T3, on a Mac mini 1.42GHz box.

Solution is to run ntp?
Comment 4 Colin Charles 2005-05-17 20:19:44 EDT
Just talked to benh about this, and it seems that the probed OF data might be
whats wrong; he needs something to create a sane base out of. 

cc'ing dwmw2 too
Comment 5 Dave Jones 2005-06-27 19:30:24 EDT
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
so).

Thanks.
Comment 6 John Reiser 2005-06-27 21:55:21 EDT
Booting FC4 final release kernel-2.6.11-1.1369_FC4 on Mac mini (PowerPC32) loses
10 seconds in 56 minutes (1:336); Mac OS X 10.3.9 on the same box keeps accurate
time over 61 minutes elapsed.  So the problem is still there in FC4.
Comment 7 Dave Jones 2005-07-15 17:51:34 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 8 John Reiser 2005-07-15 21:25:59 EDT
The problem still occurs in kernel-2.6.12-1.1398_FC4 on the same box (ppc32:
Apple Macintosh mini).  The actual loss was 9 seconds in 50.50 minutes (1:337).
 The actual elapsed time was 50 minutes 30 seconds; the indicated elapsed time
was 50 minutes 21 seconds.  Run level 5, but X11 failed to start [bug somewhere
in radeon 9200 support], so X11 disabled itself.  Machine otherwise idle:
default crontab [no updatedb], etc.)
Comment 9 Dave Jones 2005-09-30 02:38:47 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 10 John Reiser 2005-09-30 16:58:40 EDT
Booting directly to single-user mode of kernel-2.6.13-1.1526_FC4, then
subtracting two outputs of /bin/date that were invoked 30.00 minutes apart, the
clock lost 5 seconds with reference to a quartz-stabilized external clock.  This
is a ratio of 1:360.
Comment 11 Dave Jones 2005-11-10 14:41:59 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 12 John Reiser 2005-11-10 23:55:02 EST
kernel-2.6.14-1.1637_FC4 on my PowerPC-32 Apple Mac mini still loses 6 seconds
in 30:00 minutes.  (An external quartz-stabilized clock shows 30:00 elapsed,
while /bin/date shows 29:54 elapsed.)  Apple MacOS X 3.9 keeps good time on the
same machine.
Comment 13 John Reiser 2005-11-11 00:39:15 EST
ubuntu-5.10-live-powerpc (kernel-2.6.12-9-powerpc built Mon Oct.10) loses 5
seconds in 30:00.
Comment 14 Dave Jones 2006-02-03 01:55:38 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
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_REPORTER 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.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 15 John Reiser 2006-02-07 00:42:23 EST
The problem still exists in kernel-2.6.15-1.1909_FC5 for ppc (32-bit Apple
Macintosh mini).  The machine's clock (as reported by /bin/date) said that
29min55sec had elapsed when an external quartz-stabilized clock indicated
30min00sec had elapsed.  The slowdown is 5:1800 or 1:360.  [Changed Version to
fc5test2.]
Comment 16 Dave Jones 2006-10-16 17:26:37 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 17 John Reiser 2006-10-17 12:35:31 EDT
The problem persists in kernel-2.6.18-1.2784.fc6 (Fedora Core 6 Pre).  Actual
duration of 32m22s by external quartz clock was measured as 32m15s by /bin/date.
 System fell behind by 7 seconds over a span of 32 minutes.  By contrast, Apple
Macintosh OS X 10.4.7 kept accurate time (within 1 second) during the 31 minutes
preceding the test of FC6pre.  Network cable was disconnected during both tests
to prevent "cheating" by use of ntpd (network time protocol daemon).
Comment 18 Bug Zapper 2008-04-03 12:09:58 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 19 John Reiser 2008-04-03 20:20:22 EDT
The problem persists in Fedora 8 kernel-2.6.24.4-64.fc8 on Power PC Apple
Macintosh Mini (G4 cpu).  The measured loss was 9 seconds over the course of
55:00 (55 minutes 0 seconds), or a ratio of 1:367.

The comparison system of Mac OS X 10.4.11 on the same hardware stayed exactly on
time over 2:05:30 (two hours five minutes 30 seconds).  Intermediate checks
every 20 minutes or so also under Mac OS X agreed exactly with the reference
external quartz clock.  The system sleep threshhold was set to one hour.  The
display blanked for inactivity, but the machine never slept.

The network cable was unplugged, there is no wireless network card in the box,
the box could not communicate with any other machine.  In particular there was
no chance that Network Time Protocol daemon on Mac OS X was synchronizing.
Comment 20 John Reiser 2008-04-03 21:30:53 EDT
I have provided the requested information in comment #19 above.
Bugzilla will not let me change the "Version" to 8; anybody?
Comment 21 Thomas Gleixner 2008-04-04 15:35:52 EDT
Hmm, I'm not really the person to answer questions how the PPC folks figure out
on which frequency the incrementer runs from those mac minis.

The generic code relies on accurate info from the arch code which provides the
clock source hardware driver.

Thanks,
        tglx
Comment 22 Dave Jones 2008-04-04 15:56:37 EDT
Lets see if our ppc guy has some ideas :)
Thanks Thomas.
Comment 24 Bug Zapper 2008-11-26 01:50:24 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 John Reiser 2008-11-28 13:27:15 EST
The problem persists in kernel-2.6.27.5-117.fc10.ppc.  The time reported by /bin/date lost 5 seconds over an interval of 30 minutes (1:360) as measured by an external quartz clock.  No ntp (network time protocol) daemon was running; the system sat in Gnome terminal under X11 with no user-initiated tasks.
Comment 26 Bug Zapper 2009-11-18 03:03:37 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 27 John Reiser 2009-11-18 13:26:16 EST
The problem persists in kernel-2.6.31.5-227.fc12.ppc.  The measured loss was 9 seconds in 50 minutes, or 1:333.  [Changing Version of this bug to "12".]
Comment 28 John Reiser 2009-11-18 14:38:10 EST
The problem does *NOT* appear with kernel-2.6.31.5-227.fc12.ppc on a PowerMac8,2 (PPC970FX with altivec) detected as 414 (unknown, Shasta-based) rev 3.0 (pvr 003c 0300).  The clock was rock-steady for a duration of 30 minutes.  So the problem appears to be specific to the Mac Mini PowerPC.
Comment 29 Bug Zapper 2010-11-04 08:19:05 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 Bug Zapper 2010-12-05 02:19:14 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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