Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1722724 > unrolled thread
| Started by | Luboš Doležel <lubos@dolezel.info> |
|---|---|
| First post | 2017-08-29 21:20 +0200 |
| Last post | 2017-08-30 00:30 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
Unable to move system time back on recent Core i7 systems Luboš Doležel <lubos@dolezel.info> - 2017-08-29 21:20 +0200
Re: Unable to move system time back on recent Core i7 systems Randy Dunlap <rdunlap@infradead.org> - 2017-08-30 00:20 +0200
Re: Unable to move system time back on recent Core i7 systems Luboš Doležel <lubos@dolezel.info> - 2017-08-30 00:30 +0200
| From | Luboš Doležel <lubos@dolezel.info> |
|---|---|
| Date | 2017-08-29 21:20 +0200 |
| Subject | Unable to move system time back on recent Core i7 systems |
| Message-ID | <ujUdk-6Et-25@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Randy Dunlap <rdunlap@infradead.org> |
|---|---|
| Date | 2017-08-30 00:20 +0200 |
| Message-ID | <ujX1w-8qU-13@gated-at.bofh.it> |
| In reply to | #1722724 |
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
[toc] | [prev] | [next] | [standalone]
| From | Luboš Doležel <lubos@dolezel.info> |
|---|---|
| Date | 2017-08-30 00:30 +0200 |
| Message-ID | <ujXbb-8u5-7@gated-at.bofh.it> |
| In reply to | #1722887 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web