Re: frozen clock on Intel NUC

2017-10-21 Thread Joe Gidi 
>> >> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov 
>> >> wrote:
>> >> >
>> >> > Looks like your acpitimer takes a bit too much to obtain the value
>> >> > and exceeds the threshold that we've imposed.  Adam, I'd like to
>> >> > commit the diff below but unsure how many successes should we
>> consider
>> >> > before accepting the value.
>> >>
>> >> That is a very good question, i am am sorry i don't
>> >> have any information on number of failed/successful attempts, so i
>> can
>> >> not
>> >> offer any great insights.
>> >>
>> >
>> > He had 0/3.  I've decided to go for 2 out of 3 as a success for now,
>> but
>> > increased the threshold to 50.  We'll see what drift values these
>> systems
>> > will be observing.
>> >
>> > Joe, could you please update tsc.c to rev1.3 and if tsc will be picked
>> up
>> > as a timecounter by the system (sysctl -n kern.timecounter.hardware)
>> see
>> > what clock drift your system is going to develop in about a day
>> > (cat /var/db/ntpd.drift).
>>
>> Clock drift is at -16.829. Other amd64 boxes here are at -10.408 and
>> -0.812.
>>
>
> That's acceptable if it's not much worse than it was before...
> Do you have the old number?  You can switch to acpitimer and
> run it for a day with "kern.timecounter.hardware=acpitimer0".

After a day with acpitimer0, drift is -15.565. Not a very big difference.

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: frozen clock on Intel NUC

2017-10-19 Thread Mike Belopuhov 
On Thu, Oct 19, 2017 at 08:25 -0400, Joe Gidi wrote:
> >> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov 
> >> wrote:
> >> >
> >> > Looks like your acpitimer takes a bit too much to obtain the value
> >> > and exceeds the threshold that we've imposed.  Adam, I'd like to
> >> > commit the diff below but unsure how many successes should we consider
> >> > before accepting the value.
> >>
> >> That is a very good question, i am am sorry i don't
> >> have any information on number of failed/successful attempts, so i can
> >> not
> >> offer any great insights.
> >>
> >
> > He had 0/3.  I've decided to go for 2 out of 3 as a success for now, but
> > increased the threshold to 50.  We'll see what drift values these systems
> > will be observing.
> >
> > Joe, could you please update tsc.c to rev1.3 and if tsc will be picked up
> > as a timecounter by the system (sysctl -n kern.timecounter.hardware) see
> > what clock drift your system is going to develop in about a day
> > (cat /var/db/ntpd.drift).
> 
> Clock drift is at -16.829. Other amd64 boxes here are at -10.408 and -0.812.
>

That's acceptable if it's not much worse than it was before...
Do you have the old number?  You can switch to acpitimer and
run it for a day with "kern.timecounter.hardware=acpitimer0".

> Thanks,
> 
> -- 
> 
> Joe Gidi
> j...@entropicblur.com
> 
> "You cannot buy skill." -- Ross Seyfried
>

Re: frozen clock on Intel NUC

2017-10-19 Thread Joe Gidi 
>> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov 
>> wrote:
>> >
>> > Looks like your acpitimer takes a bit too much to obtain the value
>> > and exceeds the threshold that we've imposed.  Adam, I'd like to
>> > commit the diff below but unsure how many successes should we consider
>> > before accepting the value.
>>
>> That is a very good question, i am am sorry i don't
>> have any information on number of failed/successful attempts, so i can
>> not
>> offer any great insights.
>>
>
> He had 0/3.  I've decided to go for 2 out of 3 as a success for now, but
> increased the threshold to 50.  We'll see what drift values these systems
> will be observing.
>
> Joe, could you please update tsc.c to rev1.3 and if tsc will be picked up
> as a timecounter by the system (sysctl -n kern.timecounter.hardware) see
> what clock drift your system is going to develop in about a day
> (cat /var/db/ntpd.drift).

Clock drift is at -16.829. Other amd64 boxes here are at -10.408 and -0.812.

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: frozen clock on Intel NUC

2017-10-17 Thread Adam Steen 
On Wed, Oct 18, 2017 at 12:08 AM, Mike Belopuhov  wrote:
> On Tue, Oct 17, 2017 at 20:11 +0800, Adam Steen wrote:
>> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov  wrote:
>> >
>> > Looks like your acpitimer takes a bit too much to obtain the value
>> > and exceeds the threshold that we've imposed.  Adam, I'd like to
>> > commit the diff below but unsure how many successes should we consider
>> > before accepting the value.
>>
>> That is a very good question, i am am sorry i don't
>> have any information on number of failed/successful attempts, so i can not
>> offer any great insights.
>>
>
> He had 0/3.  I've decided to go for 2 out of 3 as a success for now, but
> increased the threshold to 50.  We'll see what drift values these systems
> will be observing.
>
> Joe, could you please update tsc.c to rev1.3 and if tsc will be picked up
> as a timecounter by the system (sysctl -n kern.timecounter.hardware) see
> what clock drift your system is going to develop in about a day
> (cat /var/db/ntpd.drift).
>
>> My original code was loosely base on the links you gave me in my inital 
>> thread
>> about a tsc based timer. [0]
>>
>> > Any particular reason you've picked the
>> > minimum frequency out of all?
>>
>> I pick the minimum mostly due to the lines 773-775 [1] and line 834 [2]
>> of tsc.c in the linux kernel and it was cleaner code than doing an average.
>>
>> > Should we consider increasing the
>> > threshold as well?
>>
>> Linux uses a 10% leeway [3], either side of the expected value. I think that,
>> increasing the threadhold would be worth testing, i didn't play with the 
>> figure
>> much, as it seemed to just work for me.
>>
>
> 10% would be quite a bit more than 20 or 50..
>
>> Or do we need todo something similar to [4], but adapted to our code.
>>
>
> This would just bump the delay 5 times, right?  Or do you think it might
> be more than that?

Yes that is my understanding, it just bumps the delay.

Adam

>
>> /*
>> * Check whether PIT failed more than once. This
>> * happens in virtualized environments. We need to
>> * give the virtual PC a slightly longer timeframe for
>> * the HPET/PMTIMER to make the result precise.
>> */
>>
>> Please let me know if you would like me to look into and test
>> somethings further.
>>
>> Adam
>>
>> [0] https://marc.info/?l=openbsd-misc=150148792804747=2
>> [1] 
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L773
>> [2] 
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L834
>> [3] 
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L841
>> [4] 
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L852
>>

Re: frozen clock on Intel NUC

2017-10-17 Thread Joe Gidi 
>> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov 
>> wrote:
>> >
>> > Looks like your acpitimer takes a bit too much to obtain the value
>> > and exceeds the threshold that we've imposed.  Adam, I'd like to
>> > commit the diff below but unsure how many successes should we consider
>> > before accepting the value.
>>
>> That is a very good question, i am am sorry i don't
>> have any information on number of failed/successful attempts, so i can
>> not
>> offer any great insights.
>>
>
> He had 0/3.  I've decided to go for 2 out of 3 as a success for now, but
> increased the threshold to 50.  We'll see what drift values these systems
> will be observing.
>
> Joe, could you please update tsc.c to rev1.3 and if tsc will be picked up
> as a timecounter by the system (sysctl -n kern.timecounter.hardware) see
> what clock drift your system is going to develop in about a day
> (cat /var/db/ntpd.drift).

Updated to the latest snapshot, dmesg shows:

acpitimer0: recalibrated TSC frequency 1599946224 Hz

$ sysctl -n kern.timecounter.hardware
tsc

I will let the box run for a day or so and let you know about the clock
drift.

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: frozen clock on Intel NUC

2017-10-17 Thread Mike Belopuhov 
On Tue, Oct 17, 2017 at 20:11 +0800, Adam Steen wrote:
> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov  wrote:
> >
> > Looks like your acpitimer takes a bit too much to obtain the value
> > and exceeds the threshold that we've imposed.  Adam, I'd like to
> > commit the diff below but unsure how many successes should we consider
> > before accepting the value.
> 
> That is a very good question, i am am sorry i don't
> have any information on number of failed/successful attempts, so i can not
> offer any great insights.
>

He had 0/3.  I've decided to go for 2 out of 3 as a success for now, but
increased the threshold to 50.  We'll see what drift values these systems
will be observing.

Joe, could you please update tsc.c to rev1.3 and if tsc will be picked up
as a timecounter by the system (sysctl -n kern.timecounter.hardware) see
what clock drift your system is going to develop in about a day
(cat /var/db/ntpd.drift).

> My original code was loosely base on the links you gave me in my inital thread
> about a tsc based timer. [0]
> 
> > Any particular reason you've picked the
> > minimum frequency out of all?
> 
> I pick the minimum mostly due to the lines 773-775 [1] and line 834 [2]
> of tsc.c in the linux kernel and it was cleaner code than doing an average.
> 
> > Should we consider increasing the
> > threshold as well?
> 
> Linux uses a 10% leeway [3], either side of the expected value. I think that,
> increasing the threadhold would be worth testing, i didn't play with the 
> figure
> much, as it seemed to just work for me.
>

10% would be quite a bit more than 20 or 50..

> Or do we need todo something similar to [4], but adapted to our code.
>

This would just bump the delay 5 times, right?  Or do you think it might
be more than that?

> /*
> * Check whether PIT failed more than once. This
> * happens in virtualized environments. We need to
> * give the virtual PC a slightly longer timeframe for
> * the HPET/PMTIMER to make the result precise.
> */
> 
> Please let me know if you would like me to look into and test
> somethings further.
> 
> Adam
> 
> [0] https://marc.info/?l=openbsd-misc=150148792804747=2
> [1] 
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L773
> [2] 
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L834
> [3] 
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L841
> [4] 
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L852
>

Re: frozen clock on Intel NUC

2017-10-17 Thread Adam Steen 
On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov  wrote:
>
> Looks like your acpitimer takes a bit too much to obtain the value
> and exceeds the threshold that we've imposed.  Adam, I'd like to
> commit the diff below but unsure how many successes should we consider
> before accepting the value.

That is a very good question, i am am sorry i don't
have any information on number of failed/successful attempts, so i can not
offer any great insights.

My original code was loosely base on the links you gave me in my inital thread
about a tsc based timer. [0]

> Any particular reason you've picked the
> minimum frequency out of all?

I pick the minimum mostly due to the lines 773-775 [1] and line 834 [2]
of tsc.c in the linux kernel and it was cleaner code than doing an average.

> Should we consider increasing the
> threshold as well?

Linux uses a 10% leeway [3], either side of the expected value. I think that,
increasing the threadhold would be worth testing, i didn't play with the figure
much, as it seemed to just work for me.

Or do we need todo something similar to [4], but adapted to our code.

/*
* Check whether PIT failed more than once. This
* happens in virtualized environments. We need to
* give the virtual PC a slightly longer timeframe for
* the HPET/PMTIMER to make the result precise.
*/

Please let me know if you would like me to look into and test
somethings further.

Adam

[0] https://marc.info/?l=openbsd-misc=150148792804747=2
[1] 
http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L773
[2] 
http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L834
[3] 
http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L841
[4] 
http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L852

> On Mon, Oct 16, 2017 at 14:28 -0400, Joe Gidi wrote:
>> Hi Mike,
>>
>> I see your first printf here but not the second?
>>
>> dmesg:
>>
>> OpenBSD 6.2-current (GENERIC.MP) #1: Mon Oct 16 14:12:25 EDT 2017
>> brickf...@atom.irascible.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 4192956416 (3998MB)
>> avail mem = 4059013120 (3870MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedcb0 (49 entries)
>> bios0: vendor Intel Corp. version "PYBSWCEL.86A.0064.2017.0815.1055" date
>> 08/15/2017
>> bios0: Intel Corporation NUC5CPYB
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT TPM2
>> CSRT SSDT
>> acpi0: wakeup devices BRCM(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4)
>> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1680.47 MHz
>> cpu0:
>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
>> cpu0: 1MB 64b/line 16-way L2 cache
>> usec 100045 tsc1 35958728300 tsc2 36118795820 count1 13341437 count2 13699553
>> usec 100045 tsc1 36119540340 tsc2 36279608540 count1 13701219 count2 14059337
>> usec 100046 tsc1 36280348700 tsc2 36440417660 count1 14060993 count2 14419115
>> cpu0: smt 0, core 0, package 0
>> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
>> cpu0: apic clock running at 79MHz
>> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
>> cpu1 at mainbus0: apid 4 (application processor)
>> cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.00 MHz
>> cpu1:
>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
>> cpu1: 1MB 64b/line 16-way L2 cache
>> cpu1: smt 0, core 2, package 0
>> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
>> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
>> acpiprt0 at acpi0: bus 0 (PCI0)
>> acpiprt1 at acpi0: bus 1 (RP01)
>> acpiprt2 at acpi0: bus 2 (RP02)
>> acpiprt3 at acpi0: bus 3 (RP03)
>> acpiprt4 at acpi0: bus -1 (RP04)
>> acpiec0 at acpi0: not present
>> acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
>> acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
>> acpipwrres0 at acpi0: ID3C, resource for ISP3
>> acpipwrres1 at acpi0: CLK0, resource for CAMD
>> acpipwrres2 at acpi0: CLK0
>> acpipwrres3 at acpi0: CLK1, resource for CAM3
>> acpipwrres4 at acpi0: USBC, resource for XHC1
>> acpipwrres5 at acpi0: FN00, resource for FAN0
>> acpitz0 at acpi0: critical temperature is 115 degC
>> chvgpio0 at acpi0: GPO1 uid 2 addr

Re: frozen clock on Intel NUC

2017-10-17 Thread Mike Belopuhov 

Looks like your acpitimer takes a bit too much to obtain the value
and exceeds the threshold that we've imposed.  Adam, I'd like to
commit the diff below but unsure how many successes should we consider
before accepting the value.  Any particular reason you've picked the
minimum frequency out of all?  Should we consider increasing the
threshold as well?

On Mon, Oct 16, 2017 at 14:28 -0400, Joe Gidi wrote:
> Hi Mike,
> 
> I see your first printf here but not the second?
> 
> dmesg:
> 
> OpenBSD 6.2-current (GENERIC.MP) #1: Mon Oct 16 14:12:25 EDT 2017
> brickf...@atom.irascible.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4192956416 (3998MB)
> avail mem = 4059013120 (3870MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedcb0 (49 entries)
> bios0: vendor Intel Corp. version "PYBSWCEL.86A.0064.2017.0815.1055" date
> 08/15/2017
> bios0: Intel Corporation NUC5CPYB
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT TPM2
> CSRT SSDT
> acpi0: wakeup devices BRCM(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4)
> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1680.47 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu0: 1MB 64b/line 16-way L2 cache
> usec 100045 tsc1 35958728300 tsc2 36118795820 count1 13341437 count2 13699553
> usec 100045 tsc1 36119540340 tsc2 36279608540 count1 13701219 count2 14059337
> usec 100046 tsc1 36280348700 tsc2 36440417660 count1 14060993 count2 14419115
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 4 (application processor)
> cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.00 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 2, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus 2 (RP02)
> acpiprt3 at acpi0: bus 3 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: ID3C, resource for ISP3
> acpipwrres1 at acpi0: CLK0, resource for CAMD
> acpipwrres2 at acpi0: CLK0
> acpipwrres3 at acpi0: CLK1, resource for CAM3
> acpipwrres4 at acpi0: USBC, resource for XHC1
> acpipwrres5 at acpi0: FN00, resource for FAN0
> acpitz0 at acpi0: critical temperature is 115 degC
> chvgpio0 at acpi0: GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins
> "ITE8713" at acpi0 not configured
> "BCM43241" at acpi0 not configured
> sdhc0 at acpi0: SDHC addr 0x81429000/0x1000 irq 47
> sdhc0: SDHC 3.0, 200 MHz base clock
> sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
> "INTL9C60" at acpi0 not configured
> "INTL9C60" at acpi0 not configured
> "8086228A" at acpi0 not configured
> "8086228A" at acpi0 not configured
> dwiic0 at acpi0: I2C6 addr 0x81425000/0x1000 irq 37
> iic0 at dwiic0
> dwiic1 at acpi0: I2C7 addr 0x81423000/0x1000 irq 38
> iic1 at dwiic1
> acpibtn0 at acpi0: LID0
> acpibtn1 at acpi0: SLPB
> chvgpio1 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
> chvgpio2 at acpi0: GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
> chvgpio3 at acpi0: GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
> "MSFT0101" at acpi0 not configured
> "INT3398" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> acpivideo0 at acpi0: GFX0
> cpu0: Enhanced SpeedStep 1680 MHz: speeds: 1601, 1600, 1520, 1440, 1360,
> 1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x21
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x21
> drm0 at inteldrm0
> inteldrm0: msi
> inteldrm0: 1920x1080, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x21: msi, AHCI
> 1.3.1
> ahci0: port 0: 3.0Gb/s
>

Re: frozen clock on Intel NUC

2017-10-16 Thread Joe Gidi 
Hi Mike,

I see your first printf here but not the second?

dmesg:

OpenBSD 6.2-current (GENERIC.MP) #1: Mon Oct 16 14:12:25 EDT 2017
brickf...@atom.irascible.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4192956416 (3998MB)
avail mem = 4059013120 (3870MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedcb0 (49 entries)
bios0: vendor Intel Corp. version "PYBSWCEL.86A.0064.2017.0815.1055" date
08/15/2017
bios0: Intel Corporation NUC5CPYB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT TPM2
CSRT SSDT
acpi0: wakeup devices BRCM(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4)
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1680.47 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
usec 100045 tsc1 35958728300 tsc2 36118795820 count1 13341437 count2 13699553
usec 100045 tsc1 36119540340 tsc2 36279608540 count1 13701219 count2 14059337
usec 100046 tsc1 36280348700 tsc2 36440417660 count1 14060993 count2 14419115
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: ID3C, resource for ISP3
acpipwrres1 at acpi0: CLK0, resource for CAMD
acpipwrres2 at acpi0: CLK0
acpipwrres3 at acpi0: CLK1, resource for CAM3
acpipwrres4 at acpi0: USBC, resource for XHC1
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 115 degC
chvgpio0 at acpi0: GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins
"ITE8713" at acpi0 not configured
"BCM43241" at acpi0 not configured
sdhc0 at acpi0: SDHC addr 0x81429000/0x1000 irq 47
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
"INTL9C60" at acpi0 not configured
"INTL9C60" at acpi0 not configured
"8086228A" at acpi0 not configured
"8086228A" at acpi0 not configured
dwiic0 at acpi0: I2C6 addr 0x81425000/0x1000 irq 37
iic0 at dwiic0
dwiic1 at acpi0: I2C7 addr 0x81423000/0x1000 irq 38
iic1 at dwiic1
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: SLPB
chvgpio1 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
chvgpio2 at acpi0: GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
chvgpio3 at acpi0: GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
"MSFT0101" at acpi0 not configured
"INT3398" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 1680 MHz: speeds: 1601, 1600, 1520, 1440, 1360,
1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x21
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x21
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x21: msi, AHCI
1.3.1
ahci0: port 0: 3.0Gb/s
ahci0: PHY offline on port 1
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed naa.5000c50024852fc6
sd0: 610480MB, 512 bytes/sector, 1250263728 sectors
xhci0 at pci0 dev 20 function 0 "Intel Braswell xHCI" rev 0x21: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1
"Intel Braswell TXE" rev 0x21 at pci0 dev 26 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel Braswell HD Audio" rev 0x21: msi
azalia0: codecs: Realtek/0x0283, Intel/0x2883, using Realtek/0x0283

Re: frozen clock on Intel NUC

2017-10-16 Thread Mike Belopuhov 
On Mon, Oct 16, 2017 at 16:10 +, Joe Gidi wrote:
> Hi Mike,
> 
> Thanks for the patch; it appears to fix the clock:
> 
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> 
> System time is advancing at the expected rate :-)
> 

No, nothing is fixed yet.  I'm trying to understand what's
going on.  Please try this new one instead.

diff --git sys/arch/amd64/amd64/tsc.c sys/arch/amd64/amd64/tsc.c
index ce91d5b95df..40e35defb16 100644
--- sys/arch/amd64/amd64/tsc.c
+++ sys/arch/amd64/amd64/tsc.c
@@ -148,18 +148,24 @@ measure_tsc_freq(struct timecounter *tc)
continue;
 
usec = calculate_tc_delay(tc, count1, count2);
 
if ((usec < (delay_usec - RECALIBRATE_DELAY_THRESHOLD)) ||
-   (usec > (delay_usec + RECALIBRATE_DELAY_THRESHOLD)))
+   (usec > (delay_usec + RECALIBRATE_DELAY_THRESHOLD))) {
+   printf("usec %d tsc1 %llu tsc2 %llu count1 %llu "
+   "count2 %llu\n", usec, tsc1, tsc2, count1, count2);
continue;
+   }
 
frequency = calculate_tsc_freq(tsc1, tsc2, usec);
 
min_freq = MIN(min_freq, frequency);
+   printf("tsc1 %llu tsc2 %llu freq %llu\n", tsc1, tsc2,
+   frequency);
}
 
+   min_freq = 0;
return (min_freq);
 }
 
 void
 calibrate_tsc_freq(void)

Re: frozen clock on Intel NUC

2017-10-16 Thread Mike Belopuhov 
On Sun, Oct 15, 2017 at 16:38 +, Joe Gidi wrote:
> >Synopsis:Recent TSC changes seem to result in frozen clock on Intel NUC
> >Category:kernel
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2-current (GENERIC.MP) #148: Fri Oct 13 16:30:01
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After upgrading to a recent snapshot, I noticed the following line in
> dmesg and a frozen clock once the system was up:
>   acpitimer0: recalibrated TSC frequency -1 Hz
>   I believe this is due to the recent TSC timecounter changes committed by
> mikeb.
> >How-To-Repeat:
>   Happens all the time with current snapshot.
> >Fix:
>   Disabling acpitimer in UKC is enough to bring the system up with a
> functional clock.
> 

Hi,

Thanks for the report.

Please try the patch below and show the resulting dmesg.

diff --git sys/arch/amd64/amd64/tsc.c sys/arch/amd64/amd64/tsc.c
index ce91d5b95df..9ef891dab02 100644
--- sys/arch/amd64/amd64/tsc.c
+++ sys/arch/amd64/amd64/tsc.c
@@ -121,20 +121,21 @@ calculate_tc_delay(struct timecounter *tc, uint64_t 
count1, uint64_t count2)
 uint64_t
 measure_tsc_freq(struct timecounter *tc)
 {
uint64_t count1, count2, frequency, min_freq, tsc1, tsc2;
u_long ef;
-   int delay_usec, i, err1, err2, usec;
+   int delay_usec, i, err1, err2, err3, usec;
 
/* warmup the timers */
for (i = 0; i < 3; i++) {
(void)tc->tc_get_timecount(tc);
(void)rdtsc();
}
 
min_freq = ULLONG_MAX;
 
+   err3 = 0;
delay_usec = 10;
for (i = 0; i < 3; i++) {
ef = read_rflags();
disable_intr();
 
@@ -148,18 +149,24 @@ measure_tsc_freq(struct timecounter *tc)
continue;
 
usec = calculate_tc_delay(tc, count1, count2);
 
if ((usec < (delay_usec - RECALIBRATE_DELAY_THRESHOLD)) ||
-   (usec > (delay_usec + RECALIBRATE_DELAY_THRESHOLD)))
+   (usec > (delay_usec + RECALIBRATE_DELAY_THRESHOLD))) {
+   err3++;
continue;
+   }
 
frequency = calculate_tsc_freq(tsc1, tsc2, usec);
 
min_freq = MIN(min_freq, frequency);
}
 
+   min_freq = 0;
+   if (err1 || err2)
+   printf("Recalibration err1 %d err2 %d err3 %d\n",
+   err1, err2, err3);
return (min_freq);
 }
 
 void
 calibrate_tsc_freq(void)