Re: sudden appearance of timekeeping problems with netbsd-8 just after 8.1

[Greg Troxel <gdt%lexort.com@localhost>]

Patrick Welche <prlw1%cam.ac.uk@localhost> writes:

> On Tue, Jun 18, 2019 at 04:56:33PM -0000, Michael van Elst wrote:
>> gdt%lexort.com@localhost (Greg Troxel) writes:
>> 
>> >  -timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
>> >  +timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
>> 
>> >  -timecounter: Timecounter "TSC" frequency 2800071320 Hz quality 3000
>> >  +timecounter: Timecounter "TSC" frequency 3920113160 Hz quality 3000
>> 
>> That looks like a non-invariant TSC that changes with the "turbo" mode
>> of the CPU. The interesting part is the 3.9GHz number, according to Intel
>> your CPU can only go up to 3.06GHz.

estd -f reports:
  1600 MHz
  1733 MHz
  1867 MHz
  2000 MHz
  2133 MHz
  2267 MHz
  2400 MHz
  2533 MHz
  2667 MHz
  2800 MHz
  2801 MHz

and dmesg shows

  acpicpu0 at cpu0: ACPI CPU
  acpicpu0: C1: FFH, lat   1 us, pow  1000 mW
  acpicpu0: C2: FFH, lat  17 us, pow   500 mW
  acpicpu0: C3: FFH, lat  17 us, pow   350 mW
  acpicpu0: P0: FFH, lat  10 us, pow 143000 mW, 2801 MHz, turbo boost
  acpicpu0: P1: FFH, lat  10 us, pow 130000 mW, 2800 MHz
  acpicpu0: P2: FFH, lat  10 us, pow 114000 mW, 2667 MHz
  acpicpu0: P3: FFH, lat  10 us, pow 100000 mW, 2533 MHz
  acpicpu0: P4: FFH, lat  10 us, pow 87000 mW, 2400 MHz
  acpicpu0: P5: FFH, lat  10 us, pow 76000 mW, 2267 MHz
  acpicpu0: P6: FFH, lat  10 us, pow 68000 mW, 2133 MHz
  acpicpu0: P7: FFH, lat  10 us, pow 59000 mW, 2000 MHz
  acpicpu0: P8: FFH, lat  10 us, pow 51000 mW, 1867 MHz
  acpicpu0: P9: FFH, lat  10 us, pow 44000 mW, 1733 MHz
  acpicpu0: P10: FFH, lat  10 us, pow 40000 mW, 1600 MHz
  acpicpu0: T0: FFH, lat   1 us, pow  1040 mW, 100 %
  acpicpu0: T1: FFH, lat   1 us, pow   910 mW,  88 %
  acpicpu0: T2: FFH, lat   1 us, pow   780 mW,  75 %
  acpicpu0: T3: FFH, lat   1 us, pow   650 mW,  63 %
  acpicpu0: T4: FFH, lat   1 us, pow   520 mW,  50 %
  acpicpu0: T5: FFH, lat   1 us, pow   390 mW,  38 %
  acpicpu0: T6: FFH, lat   1 us, pow   260 mW,  25 %
  acpicpu0: T7: FFH, lat   1 us, pow   130 mW,  13 %

>> >I then set:
>> >  kern.timecounter.hardware = hpet0
>> >and things seem ok, at least after 10 minutes.
>> 
>> That's what to do, you can also use the ACPI timer.

Thanks.  Interestingly, I am seeing different a ntp.drift value for hpet
vs former tsc, but that's not really surprising.

> I just hit the same very incorrect time on my everyday laptop which had
> no issues (other than SNA artifacts ;-) )  Something must have changed...

The kernel that was ok was built (which very likely means I did a cvs
update just before):

  Wed May 15 01:30:14 EDT 2019

The kernel exhibiting the bad TSC was built

  Mon Jun  3 17:19:36 EDT 2019

which if accurate gives us a small window for bisecting.

I will try the older kernel, and then see if I can search.  I wonder if
somehow with different code the cpu/tsc is being configured so that tsc
doesn't do what it used to.

Is anyone else seeing this problem?