Unable to move system time back on recent Core i7 systems

Unable to move system time back on recent Core i7 systems

[Luboš Doležel]

Hello,

I'm hitting a strange bug on some of my Linux systems with various 4.x 
kernels.

I cannot set the system time to anything before the current system time.

This includes ntpd not being able to keep the clock in sync if the 
system clock is a little too fast. So it's not limited to just setting 
the time back to the 90s, but it actually breaks time synchronization on 
my server system.

Essentially, settimeofday() and clock_settime() system calls succeed, 
but any subsequent gettimeofday() etc. call will return unaltered time.

E.g.:

$ sudo date -s 1998-08-01
Sat Aug  1 00:00:00 CEST 1998
$ date
Tue Aug 29 20:59:25 CEST 2017

I have been able to reproduce the problem on these CPUs:

* Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
* Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz

I *cannot* reproduce the problem on these CPUs, even if I boot the same 
kernel version as on the CPUs above:

* Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
* Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
* Various even older CPUs

I tried to google the problem, but turned up with nothing. This brings 
several questions:

1) What the hell?
2) Am I the only one having this problem?
3) Can the Linux kernel developers possibly do something about this, if 
this problem is confirmed?

Thanks,
Lubos

Re: Unable to move system time back on recent Core i7 systems

[Randy Dunlap]

On 08/29/17 12:10, Luboš Doležel wrote:
> Hello,
> 
> I'm hitting a strange bug on some of my Linux systems with various 4.x kernels.
> 
> I cannot set the system time to anything before the current system time.
> 
> This includes ntpd not being able to keep the clock in sync if the system clock is a little too fast. So it's not limited to just setting the time back to the 90s, but it actually breaks time synchronization on my server system.
> 
> Essentially, settimeofday() and clock_settime() system calls succeed, but any subsequent gettimeofday() etc. call will return unaltered time.
> 
> E.g.:
> 
> $ sudo date -s 1998-08-01
> Sat Aug  1 00:00:00 CEST 1998
> $ date
> Tue Aug 29 20:59:25 CEST 2017

Is ntp daemon running?

> I have been able to reproduce the problem on these CPUs:
> 
> * Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
> * Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
> 
> I *cannot* reproduce the problem on these CPUs, even if I boot the same kernel version as on the CPUs above:
> 
> * Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
> * Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
> * Various even older CPUs
> 
> I tried to google the problem, but turned up with nothing. This brings several questions:
> 
> 1) What the hell?
> 2) Am I the only one having this problem?
> 3) Can the Linux kernel developers possibly do something about this, if this problem is confirmed?


-- 
~Randy

Re: Unable to move system time back on recent Core i7 systems

[Luboš Doležel]

Dne 30.8.2017 v 00:18 Randy Dunlap napsal(a):
> On 08/29/17 12:10, Luboš Doležel wrote:
>> Hello,
>>
>> I'm hitting a strange bug on some of my Linux systems with various 4.x kernels.
>>
>> I cannot set the system time to anything before the current system time.
>>
>> This includes ntpd not being able to keep the clock in sync if the system clock is a little too fast. So it's not limited to just setting the time back to the 90s, but it actually breaks time synchronization on my server system.
>>
>> Essentially, settimeofday() and clock_settime() system calls succeed, but any subsequent gettimeofday() etc. call will return unaltered time.
>>
>> E.g.:
>>
>> $ sudo date -s 1998-08-01
>> Sat Aug  1 00:00:00 CEST 1998
>> $ date
>> Tue Aug 29 20:59:25 CEST 2017
> 
> Is ntp daemon running?
> 

Nope, not at the time of the above experiment. Neither is systemd-timesyncd.

And when I do run the NTP daemon, it is unable to correct the time, 
which is a major problem (over time as the system clock drifts).

See here:

# ntpq -p
      remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
  tik.cesnet.cz   195.113.144.238  2 u   19   64    3   19.153  -6787.7 
  0.793
  yak.osoal.org.n .GPS.            1 u   17   64    3  315.400  -6786.8 
  0.983
  golf.zq1.de     192.53.103.103   2 u   21   64    3   35.219  -6786.7 
  0.836
  manager-vlan87. 193.6.222.95     2 u   18   64    3   39.147  -6791.1 
  0.807
  stratum2-2.NTP. 129.70.130.70    2 u   21   64    3   37.787  -6786.8 
  0.885

All servers are reported to have a ~ -6700ms offset and it only grows 
over time.

Are there any other known system services that could interfere with the 
clock like this?

Lubos