Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-25 Thread Kalabic S.



On 24/10/2022 15:26, Scott Cheloha wrote:


My guess is that we are miscalibrating the TSC frequency at least
once.  The only major thing that changed in the frequency calibration
code between 7.1 and 7.2 is the introduction of additional delay(9) 
implementations.
Let's see if removing them from the picture changes the result we get.

Can you compile and boot a -current kernel with the attached patch and
send the resulting dmesg?



Patch has fixed the issue! Attaching resulting dmesg and sysctl outputs 
from recently compiled kernel.


Cheers,
- Kalabic S.OpenBSD 7.2-current (GENERIC.MP) #1: Tue Oct 25 15:57:21 UTC 2022
r...@pc118.lan4.home:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1055850496 (1006MB)
avail mem = 1006477312 (959MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) 
S1F0(S3) PE50(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpitimerattach: 6087399 21645243246
acpitimerattach: 6087421 21645247716
acpitimerattach: 6087442 21645252182
acpitimerattach: 6087463 21645256655
acpitimerattach: 6087485 21645261118
acpitimerattach: 6087506 21645265584
acpitimerattach: 6087528 21645270054
acpitimerattach: 6087549 21645274520
acpitimerattach: 6087571 21645278980
acpitimerattach: 6087592 21645283456
acpitimerattach: 6087614 21645287916
acpitimerattach: 6087635 21645292392
acpitimerattach: 6087657 21645296855
acpitimerattach: 6087678 21645301321
acpitimerattach: 6087700 21645305791
acpitimerattach: 6087721 21645310257
acpitimerattach: 6087743 21645314730
acpitimerattach: 6087764 21645319196
acpitimerattach: 6087786 21645323669
acpitimerattach: 6087807 21645328129
acpitimerattach: 6087829 21645332595
acpitimerattach: 6087850 21645337052
acpitimerattach: 6087871 21645341528
acpitimerattach: 6087893 21645345994
acpitimerattach: 6087914 21645350467
acpitimerattach: 6087936 21645354930
acpitimerattach: 6087957 21645359403
acpitimerattach: 6087979 21645363869
acpitimerattach: 6088000 21645368332
acpitimerattach: 6088022 21645372808
acpitimerattach: 6088043 21645377268
acpitimerattach: 6088065 21645381744
acpitimerattach: 6088086 21645386204
acpitimerattach: 6088108 21645390670
acpitimerattach: 6088129 21645395140
acpitimerattach: 6088151 21645399609
acpitimerattach: 6088172 21645404079
acpitimerattach: 6088194 21645408545
acpitimerattach: 6088215 21645413008
acpitimerattach: 6088237 21645417481
acpitimerattach: 6088258 21645421947
acpitimerattach: 6088280 21645426420
acpitimerattach: 6088301 21645430886
acpitimerattach: 6088322 21645435346
acpitimerattach: 6088344 21645439819
acpitimerattach: 6088365 21645444276
acpitimerattach: 6088387 21645448745
acpitimerattach: 6088408 21645875421
acpitimerattach: 6088430 21645879881
acpitimerattach: 6088451 21645884341
acpitimerattach: 6088473 2164504
acpitimerattach: 6088494 21645893280
acpitimerattach: 6088516 21645897743
acpitimerattach: 6088537 21645902200
acpitimerattach: 6088559 21645906670
acpitimerattach: 6088580 21645911130
acpitimerattach: 6088602 21645915593
acpitimerattach: 6088623 21645920050
acpitimerattach: 6088645 21645924523
acpitimerattach: 6088666 21645928980
acpitimerattach: 6088688 21645933440
acpitimerattach: 6088709 21645937903
acpitimerattach: 6088731 21645942373
acpitimerattach: 6088752 21645946836
acpitimerattach: 6088773 21645951293
acpitimerattach: 6088795 21645955753
acpitimerattach: 6088816 21645960217
acpitimerattach: 6088838 21645964680
acpitimerattach: 6088859 21645969140
acpitimerattach: 601 21645973613
acpitimerattach: 6088902 21645978895
acpitimerattach: 6088924 21645983371
acpitimerattach: 6088945 21645987837
acpitimerattach: 6088967 21645992303
acpitimerattach: 6088988 21645996770
acpitimerattach: 6089010 21646001236
acpitimerattach: 6089031 21646005696
acpitimerattach: 6089053 21646010169
acpitimerattach: 6089074 21646014635
acpitimerattach: 6089096 21646019111
acpitimerattach: 6089117 21646023574
acpitimerattach: 6089139 21646028037
acpitimerattach: 6089160 21646032510
acpitimerattach: 6089181 21646036976
acpitimerattach: 6089203 21646041449
acpitimerattach: 6089224 21646045912
acpitimerattach: 6089246 21646050385
acpitimerattach: 6089267 21646054845
acpitimerattach: 6089289 21646059311
acpitimerattach: 6089310 21646063781
acpitimerattach: 6089332 21646068247
acpitimerattach: 6089353 21646072713
acpitimerattach: 6089375 21646077186
acpitimerattach: 6089396 21646081649
acpitimerattach: 6089418 21646086119
acpitimerattach: 6089439 21646090588
acpitimerattach: 6089461 21646095061
acpitimerattach: 6089482 21646099527

Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Kalabic S.

On 25/10/2022 00:17, Kalabic S. wrote:

On 24/10/2022 21:31, Scott Cheloha wrote:

On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote:

On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote:

[...]



machdep.cpuvendor=GenuineIntel
machdep.cpuid=0x306a9
machdep.cpufeature=0x1fbbfbff
machdep.tscfreq=745206414
machdep.invarianttsc=1


And yeah, your TSC frequency is astoundingly high.  Way higher than
anything I have ever seen.


Sorry, what I should have said was: that TSC frequency is too *low*
for your machine.  I miscounted the number of decimal digits.

To be clear: the measured TSC frequency of 745 MHz seems too low.



There is something probably relevant that I noticed while setting up a 
new VM guest to try to compile the kernel as advised.


So, ISO used was a current snapshot (sha256: 29d320ae1a...), and as 
always in "VM Options" under "General Options", "Guest OS Version" was 
set to "FreeBSD (32-bit)". Issue with clock running forward is again 
reproduced.


Being curious what would happen if that same option was set to "FreeBSD 
(64-bit)" I tried it and the clock issue is gone!
(but ESXi now shows a warning in web GUI: 'The configured guest OS 
(FreeBSD (64-bit)) for this virtual machine does not match the guest 
that is currently running (FreeBSD (32-bit)). ...')


Attached are dmesg, sysctl hw and sysctl machdep outputs from this new 
VM running with both 32 and 64 bit settings. *Nothing* else was changed, 
virtual machine was untouched after installation.


Notable difference is machdep.tscfreq=3392313140 (64-bit) vs 744231460 
for 32-bit setting.


Hope this helps for now.


Just noticed hw.sensors.vmt0.timedelta0 and hw.cpuspeed are also 
different depending on Guest OS Version option!


For 32-bit option (reproducible clock issue):
hw.sensors.vmt0.timedelta0=738.817611 secs
hw.cpuspeed=744

For 64-bit option (no clock issue):
hw.sensors.vmt0.timedelta0=941.876986 secs
hw.cpuspeed=3392



Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Kalabic S.

On 24/10/2022 21:31, Scott Cheloha wrote:

On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote:

On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote:

[...]



machdep.cpuvendor=GenuineIntel
machdep.cpuid=0x306a9
machdep.cpufeature=0x1fbbfbff
machdep.tscfreq=745206414
machdep.invarianttsc=1


And yeah, your TSC frequency is astoundingly high.  Way higher than
anything I have ever seen.


Sorry, what I should have said was: that TSC frequency is too *low*
for your machine.  I miscounted the number of decimal digits.

To be clear: the measured TSC frequency of 745 MHz seems too low.



There is something probably relevant that I noticed while setting up a 
new VM guest to try to compile the kernel as advised.


So, ISO used was a current snapshot (sha256: 29d320ae1a...), and as 
always in "VM Options" under "General Options", "Guest OS Version" was 
set to "FreeBSD (32-bit)". Issue with clock running forward is again 
reproduced.


Being curious what would happen if that same option was set to "FreeBSD 
(64-bit)" I tried it and the clock issue is gone!
(but ESXi now shows a warning in web GUI: 'The configured guest OS 
(FreeBSD (64-bit)) for this virtual machine does not match the guest 
that is currently running (FreeBSD (32-bit)). ...')


Attached are dmesg, sysctl hw and sysctl machdep outputs from this new 
VM running with both 32 and 64 bit settings. *Nothing* else was changed, 
virtual machine was untouched after installation.


Notable difference is machdep.tscfreq=3392313140 (64-bit) vs 744231460 
for 32-bit setting.


Hope this helps for now.OpenBSD 7.2-current (GENERIC.MP) #809: Mon Oct 24 10:29:46 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1055850496 (1006MB)
avail mem = 1006489600 (959MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) 
S1F0(S3) PE50(S3) [...]
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) Core(TM) i5-3570 CPU @ 3.40GHz, 744.29 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 14MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 745.91 MHz, 06-3a-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled
"VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
mpi0 at pci0 dev 16 function 0 "Symbios Logic 

Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Scott Cheloha
On Mon, Oct 24, 2022 at 08:26:30AM -0500, Scott Cheloha wrote:
> On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote:
> > [...]
> 
> > machdep.cpuvendor=GenuineIntel
> > machdep.cpuid=0x306a9
> > machdep.cpufeature=0x1fbbfbff
> > machdep.tscfreq=745206414
> > machdep.invarianttsc=1
> 
> And yeah, your TSC frequency is astoundingly high.  Way higher than
> anything I have ever seen.

Sorry, what I should have said was: that TSC frequency is too *low*
for your machine.  I miscounted the number of decimal digits.

To be clear: the measured TSC frequency of 745 MHz seems too low.



Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Kalabic S.




On 24/10/2022 15:26, Scott Cheloha wrote:

machdep.cpuvendor=GenuineIntel
machdep.cpuid=0x306a9
machdep.cpufeature=0x1fbbfbff
machdep.tscfreq=745206414
machdep.invarianttsc=1


And yeah, your TSC frequency is astoundingly high.  Way higher than
anything I have ever seen.

My guess is that we are miscalibrating the TSC frequency at least
once.  The only major thing that changed in the frequency calibration
code between 7.1 and 7.2 is the introduction of additional delay(9) 
implementations.
Let's see if removing them from the picture changes the result we get.

Can you compile and boot a -current kernel with the attached patch and
send the resulting dmesg?



Yes I could, but it will take me some time, I never ever compiled a 
kernel :D




Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Kalabic S.



On 24/10/2022 15:26, Scott Cheloha wrote:


Please provide a dmesg and the output of

$ sysctl hw

and

$ sysctl machdep

A dmesg from the VM before you upgraded will also help.


I'm not seeing one here.  I guess I'll just do a little guesswork.



Well only thing I could do is install a new 7.1 guest on the same ESXi 
host and I did just that now. Here they are attached to this mail.
OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1055850496 (1006MB)
avail mem = 1006624768 (959MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) 
S1F0(S3) PE50(S3) [...]
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) Core(TM) i5-3570 CPU @ 3.40GHz, 3392.99 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3392.41 MHz, 06-3a-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: disabling user TSC (skew=-6189)
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled
"VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 2 int 17
mpi0: 0, firmware 1.3.41.32
scsibus1 at mpi0: 16 targets, initiator 7
sd0 at scsibus1 targ 0 lun 0: 
sd0: 32768MB, 512 bytes/sector, 67108864 sectors
mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1
ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02
pci2 at ppb1 bus 2
uhci0 at pci2 dev 0 function 0 "VMware UHCI" rev 0x00: apic 2 int 18
em0 at pci2 dev 1 function 0 "Intel 82545EM" rev 0x01: apic 2 int 19, address 
00:0c:29:ba:42:cd
ehci0 at pci2 dev 2 function 0 "VMware EHCI" rev 0x00: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "VMware EHCI root hub" rev 2.00/1.00 
addr 1
ahci0 at pci2 dev 4 function 0 "VMware AHCI" rev 0x00: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus2 at ahci0: 32 targets
cd0 at scsibus2 targ 0 lun 0:  removable
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "VMware UHCI root hub" rev 1.00/1.00 
addr 1
ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 21 function 1 "VMware PCIE" rev 0x01: msi
pci4 at ppb3 bus 4
ppb4 at pci0 dev 21 function 2 "VMware PCIE" rev 0x01: msi
pci5 at ppb4 bus 5
ppb5 at pci0 dev 21 function 3 "VMware PCIE" rev 0x01: msi
pci6 at ppb5 bus 6
ppb6 at pci0 dev 21 function 4 "VMware PCIE" rev 0x01: msi
pci7 at ppb6 bus 7
ppb7 

Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Stuart Henderson
On 2022/10/24 08:26, Scott Cheloha wrote:
> > pppoe0: received unexpected PADO
> > [snip]
> > pppoe0: received unexpected PADO
> > pppoe0: LCP keepalive timeout
> > [snip]
> > pppoe0: host unique tag found, but it belongs to a connection in state 3
> > pppoe: received PADO but could not find request for it
> > pppoe0: LCP keepalive timeout
> > pppoe0: received unexpected PADO
> > [snip]
> > pppoe0: received unexpected PADO
> 
> I assume you didn't see these messages on 7.1?

Unlikely to be related to the time issues.

These can happen if the machine is restarted without bringing down the
connection nicely first and the ISP holds onto the old session for a while.

"ifconfig pppoe0 down" in rc.shutdown, possibly followed by a short
sleep, might help with those.



Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-24 Thread Scott Cheloha
On Sun, Oct 23, 2022 at 02:07:12PM +0200, Kalabic S. wrote:
> On 23/10/2022 12:28, Scott Cheloha wrote:
> > On Fri, Oct 21, 2022 at 12:28:26AM +0200, Kalabic S. wrote:
> > > Hello,
> > > 
> > > I noticed a system clock issue after upgrade from 7.1 to 7.2, clock 
> > > started
> > > to run really fast, almost at 10x speed or so. It is a virtual machine 
> > > guest
> > > on ESXi 6.0 host, VM is used as a main Internet router for my home network
> > > (PPPoE over fiber). Both host and VM are configured with date/time in UTC
> > > timezone.
> > > 
> > > Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' has
> > > fixed it.
> > > 
> > > It did not make any difference if ntpd service was enabled or disabled.
> > 
> > Please provide a dmesg and the output of
> > 
> > $ sysctl hw
> > 
> > and
> > 
> > $ sysctl machdep
> > 
> > A dmesg from the VM before you upgraded will also help.

I'm not seeing one here.  I guess I'll just do a little guesswork.

> > If you have some kind of configuration file for the ESXi host and the
> > VM, that will also help.  I don't know anything about ESXi, but it
> > will help to look at what sort of settings you are using.

Also not seeing this here.  If you provide one it might save a lot of
time chasing non-problems.

> Attached output to this mail.

Thanks, let's take a peek.

> OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1055850496 (1006MB)
> avail mem = 1006510080 (959MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
> bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
> bios0: VMware, Inc. VMware Virtual Platform

Okay, we're in a VMware guest, no surprises there.

> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
> acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
> S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) 
> S1F0(S3) PE50(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits

You have a 24-bit virtual ACPI PM timer.

At this point in the boot, we will have switched from i8254_delay() to
using acpitimer_delay().

We probably also calibrate the TSC with acpitimer(4) here,
or near here.

> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 745.35 MHz, 06-3a-09

The bogomips measurement is very, very low compared to the speed
advertised in the CPU string.

Not necessarily an error, but odd-looking, even in a VM.

> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN

TSC-related feature flags: TSC, DEADLINE, RDTSCP, ITSC, TSC_ADJUST

> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 15MHz

This looks low.

I don't know precisely what the hypervisor does to the local apic
timer frequency, and I don't have an old dmesg for reference, but my
guess is that this value is wrong.

At this point in the boot we have switched from acpitimer_delay() to
lapic_delay().

> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.12 MHz, 06-3a-09
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.24 MHz, 06-3a-09
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
> cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 

Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-23 Thread Kalabic S.

On 23/10/2022 12:28, Scott Cheloha wrote:

On Fri, Oct 21, 2022 at 12:28:26AM +0200, Kalabic S. wrote:

Hello,

I noticed a system clock issue after upgrade from 7.1 to 7.2, clock started
to run really fast, almost at 10x speed or so. It is a virtual machine guest
on ESXi 6.0 host, VM is used as a main Internet router for my home network
(PPPoE over fiber). Both host and VM are configured with date/time in UTC
timezone.

Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' has
fixed it.

It did not make any difference if ntpd service was enabled or disabled.


Please provide a dmesg and the output of

$ sysctl hw

and

$ sysctl machdep

A dmesg from the VM before you upgraded will also help.

If you have some kind of configuration file for the ESXi host and the
VM, that will also help.  I don't know anything about ESXi, but it
will help to look at what sort of settings you are using.



Attached output to this mail.

Regards,
- Kalabic S.OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1055850496 (1006MB)
avail mem = 1006510080 (959MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (556 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/21/2015
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) 
S1F0(S3) PE50(S3) [...]
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) Core(TM) i5-3570 CPU @ 3.40GHz, 745.35 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 15MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.12 MHz, 06-3a-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 813.24 MHz, 06-3a-09
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 975.57 MHz, 06-3a-09
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
8-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 

Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-23 Thread Scott Cheloha
On Fri, Oct 21, 2022 at 12:28:26AM +0200, Kalabic S. wrote:
> Hello,
> 
> I noticed a system clock issue after upgrade from 7.1 to 7.2, clock started
> to run really fast, almost at 10x speed or so. It is a virtual machine guest
> on ESXi 6.0 host, VM is used as a main Internet router for my home network
> (PPPoE over fiber). Both host and VM are configured with date/time in UTC
> timezone.
> 
> Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' has
> fixed it.
> 
> It did not make any difference if ntpd service was enabled or disabled.

Please provide a dmesg and the output of

$ sysctl hw

and

$ sysctl machdep

A dmesg from the VM before you upgraded will also help.

If you have some kind of configuration file for the ESXi host and the
VM, that will also help.  I don't know anything about ESXi, but it
will help to look at what sort of settings you are using.



Re: Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-21 Thread Apartman Ližnjan

On 21/10/2022 00:28, Kalabic S. wrote:

Hello,

I noticed a system clock issue after upgrade from 7.1 to 7.2, clock 
started to run really fast, almost at 10x speed or so. It is a virtual 
machine guest on ESXi 6.0 host, VM is used as a main Internet router for 
my home network (PPPoE over fiber). Both host and VM are configured with 
date/time in UTC timezone.


Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' 
has fixed it.


It did not make any difference if ntpd service was enabled or disabled.

Regards,
Kalabic S.


Pretty sure Jim on Twitter is talking about the same issue, check the 
whole thread.


https://twitter.com/lippard/status/1583114388189245441

Jim mentioned he is in contact with a developer who is going to see if 
he can identify the root issue in tsc.


Hope this helps.



Had to set 'kern.timecounter.hardware' to 'acpitimer0' to fix system clock going too fast

2022-10-20 Thread Kalabic S.

Hello,

I noticed a system clock issue after upgrade from 7.1 to 7.2, clock 
started to run really fast, almost at 10x speed or so. It is a virtual 
machine guest on ESXi 6.0 host, VM is used as a main Internet router for 
my home network (PPPoE over fiber). Both host and VM are configured with 
date/time in UTC timezone.


Long story short, setting 'kern.timecounter.hardware' to 'acpitimer0' 
has fixed it.


It did not make any difference if ntpd service was enabled or disabled.

Regards,
Kalabic S.