Bug 474803 - kernel doesn't insert leap second on ppc and ia64
kernel doesn't insert leap second on ppc and ia64
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Prarit Bhargava
Red Hat Kernel QE team
: Reopened
Depends On:
Blocks: 474805
  Show dependency treegraph
 
Reported: 2008-12-05 08:10 EST by Miroslav Lichvar
Modified: 2011-10-17 10:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-17 10:19:55 EDT
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 Miroslav Lichvar 2008-12-05 08:10:01 EST
Description of problem:
On ia64 and ppc architectures leap second isn't inserted (on x86_64, i386 and s390 it seems to work fine).

In syslog there is message
kernel: Clock: inserting leap second 23:59:60 UTC

but comparing the clock against an NTP server shows that it wasn't inserted.

Version-Release number of selected component (if applicable):
kernel-2.6.18-92.el5

How reproducible:
Always

Steps to Reproduce:
1. select an NTP server
2. date -s "2008/12/31 23:59:55 UTC"; ntptime -s 16; ntpdate -q $ntpserver; sleep 10; ntpdate -q $ntpserver; ntptime -s 64; ntpdate $ntpserver 

Actual results:
No or very small difference between the offsets printed by ntpdate -q commands.

Expected results:
1 second difference.

Additional info:
Comment 1 Prarit Bhargava 2009-01-12 10:10:13 EST
Well, since the leap second has come and gone, I don't think this is a bug anymore :)

P.
Comment 2 Miroslav Lichvar 2009-01-12 10:35:12 EST
I'm pretty sure this wasn't the last one. They are usually announced 6 months before the event, so there should be some room to make a fix.

Would be good to keep this open, with very low priority for now.
Comment 3 Prarit Bhargava 2009-02-13 12:29:58 EST
Miroslav, I'm not that familiar with the output from ntpdate and ntptime, so I'm not sure exactly what looks strange or what is showing a small difference in time.

I have nec-nx2-1.rhts.bos.redhat.com reserved, with the standard RHTS password.  Do you think you could login, run the test, and copy an annotated result into the BZ?  That way I would have a better idea of what "looks" wrong.

I will note that the "inserting leap second 23:59:60 UTC" message is being output to the console, so at least the code that is supposed to execute is running.

TIA Miroslav, and sorry for the extra work,

P.
Comment 4 Miroslav Lichvar 2009-02-13 13:38:55 EST
Only output of the first and second ntpdate call is important. The difference between the offsets is -0.000449, but should be around -1.0 seconds.

Wed Dec 31 18:59:55 EST 2008
ntp_gettime() returns code 5 (ERROR)
  time cd0685fb.00860000  Wed, Dec 31 2008 18:59:55.002, (.002045),
  maximum error 16384000 us, estimated error 16384000 us
ntp_adjtime() returns code 0 (OK)
  modes 0x10 (STATUS),
  offset 0.000 us, frequency 32.113 ppm, interval 1 s,
  maximum error 16384000 us, estimated error 16384000 us,
  status 0x10 (INS),
  time constant 2, precision 1.000 us, tolerance 512 ppm,
server 10.34.33.125, stratum 3, offset 3781593.718461, delay 0.30435
31 Dec 18:59:56 ntpdate[22720]: step time server 10.34.33.125 offset 3781593.718461 sec
^^^ first offset

server 10.34.33.125, stratum 3, offset 3781593.718910, delay 0.30293
31 Dec 19:00:08 ntpdate[22787]: step time server 10.34.33.125 offset 3781593.718910 sec
^^^ second offset (after leap second)

ntp_gettime() returns code 5 (ERROR)
  time cd068608.83efe000  Wed, Dec 31 2008 19:00:08.515, (.515379),
  maximum error 16384000 us, estimated error 16384000 us
ntp_adjtime() returns code 5 (ERROR)
  modes 0x10 (STATUS),
  offset 0.000 us, frequency 32.113 ppm, interval 1 s,
  maximum error 16384000 us, estimated error 16384000 us,
  status 0x40 (UNSYNC),
  time constant 2, precision 1.000 us, tolerance 512 ppm,
31 Dec 19:00:08 ntpdate[22797]: the NTP socket is in use, exiting
Comment 5 Prarit Bhargava 2011-10-17 10:19:55 EDT
This likely isn't going to be fixed for RHEL5.  Closing as WONTFIX.

P.

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