On 2.8.2022. 23:40, Stuart Henderson wrote:
> On 2022/08/02 22:28, Hrvoje Popovski wrote:
>>
>> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>>
>>
>> r7515$ sysctl | grep tsc
>> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
>> acpihpet0(1000) acpitimer0(1
On 2022/08/02 22:28, Hrvoje Popovski wrote:
>
> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>
>
> r7515$ sysctl | grep tsc
> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
> acpihpet0(1000) acpitimer0(1000)
> machdep.tscfreq=1996246800
> machdep.invari
On 2.8.2022. 22:28, Hrvoje Popovski wrote:
> Hi,
>
> this is report from Dell R7515 with AMD EPYC 7702P 64-Core Processor
>
>
> r7515$ sysctl | grep tsc
> kern.timecounter.choice=i8254(0) mcx1(-100) mcx0(-100) tsc(-1000)
> acpihpet0(1000) acpitimer0(1000)
> machdep.tscfreq=1996246800
> machdep.i
On 31.7.2022. 5:13, Scott Cheloha wrote:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality()
On 31.7.2022. 5:13, Scott Cheloha wrote:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality()
On 31.7.2022. 5:13, Scott Cheloha wrote:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality()
From: Scott Cheloha
Date: Mon, 1 Aug 2022 11:24:21 -0500
> On Mon, Aug 01, 2022 at 03:03:36PM +0900, Masato Asou wrote:
>> Hi, Scott.
>>
>> I tested v5 patch on my ESXi on Ryzen7.
>> It works fine for me.
>
> Is this the same Ryzen7 box as in the prior message?
It's a same Ryzen7 box.
> Or do
On Mon, Aug 01, 2022 at 03:03:36PM +0900, Masato Asou wrote:
> Hi, Scott.
>
> I tested v5 patch on my ESXi on Ryzen7.
> It works fine for me.
Is this the same Ryzen7 box as in the prior message?
Or do you have two different boxes, one running OpenBSD on the bare
metal, and this one running ESXi?
Hi, Scott.
I tested v5 patch on my ESXi on Ryzen7.
It works fine for me.
$ sysctl -a | grep tsc
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
acpitimer0(1000)
machdep.tscfreq=3593269150
machdep.invarianttsc=1
$ sysctl kern.timecounter
kern.timecounter.ti
Hi, Scott.
Sorry, I missed v5 patch.
I tested v5 patch on my Ryzen7 box.
And I got failed message:
$ sysctl -a | grep tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
acpitimer0(1000)
machdep.tscfreq=3593259787
machdep.invarianttsc=1
$ sysctl kern.timecounter
kern.timecounter.tick=1
Hi, Scott
I tested your patch on my on ESXi on Ryzen7 box.
It works fine for me.
$ sysctl -a | grep tsc
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
acpitimer0(1000)
machdep.tscfreq=3593261949
machdep.invarianttsc=1
$ sysctl kern.timecounter
kern.timeco
> On Jul 31, 2022, at 23:48, Masato Asou wrote:
>
> Hi, Scott
>
> I tested your patch on my Ryzen7 box.
> And I got failed message:
>
> $ sysctl -a | grep tsc
> kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
> acpitimer0(1000)
> machdep.tscfreq=3593244667
> machdep.invarianttsc=1
>
Hi, Scott
I tested your patch on my Ryzen7 box.
And I got failed message:
$ sysctl -a | grep tsc
kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000)
acpitimer0(1000)
machdep.tscfreq=3593244667
machdep.invarianttsc=1
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timeste
Scott Cheloha writes:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality() will choose a new
Scott Cheloha [2022-07-30, 22:13 -0500]:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality() w
Hi,
At the urging of sthen@ and dv@, here is v5.
Two major changes from v4:
- Add the function tc_reset_quality() to kern_tc.c and use it
to lower the quality of the TSC timecounter if we fail the
sync test.
tc_reset_quality() will choose a new active timecounter if,
after the quality c
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Fri, 29 Jul 2022 10:51:20 -0400
>>
>> Mark Kettenis writes:
>>
>> >> From: Dave Voutila
>> >> Date: Fri, 29 Jul 2022 10:10:01 -0400
>> >>
>> >> Scott Cheloha writes:
>> >>
>> >> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wro
> From: Dave Voutila
> Date: Fri, 29 Jul 2022 10:51:20 -0400
>
> Mark Kettenis writes:
>
> >> From: Dave Voutila
> >> Date: Fri, 29 Jul 2022 10:10:01 -0400
> >>
> >> Scott Cheloha writes:
> >>
> >> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
> >> >>
> >> >> Stuart Henderso
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Fri, 29 Jul 2022 10:10:01 -0400
>>
>> Scott Cheloha writes:
>>
>> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>> >>
>> >> Stuart Henderson writes:
>> >>
>> >> > On 2022/07/28 12:57, Scott Cheloha wrote:
>> >> >> On Thu,
> From: Dave Voutila
> Date: Fri, 29 Jul 2022 10:10:01 -0400
>
> Scott Cheloha writes:
>
> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
> >>
> >> Stuart Henderson writes:
> >>
> >> > On 2022/07/28 12:57, Scott Cheloha wrote:
> >> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400,
Scott Cheloha writes:
> On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>>
>> Stuart Henderson writes:
>>
>> > On 2022/07/28 12:57, Scott Cheloha wrote:
>> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >> >
>> >> > This is breaking timecounter selection on m
Scott Cheloha [2022-07-28, 20:34 -0500]:
> On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>
>>
>> Stuart Henderson writes:
>>
>> > On 2022/07/28 12:57, Scott Cheloha wrote:
>> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >> >
>> >> > This is breaking timec
On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>
> Stuart Henderson writes:
>
> > On 2022/07/28 12:57, Scott Cheloha wrote:
> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
> >> >
> >> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
> >> > r
Stuart Henderson writes:
> On 2022/07/28 12:57, Scott Cheloha wrote:
>> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >
>> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
>> > running the latest kernel from snaps.
>>
>> Define "breaking".
>
> That's clea
> On Jul 28, 2022, at 13:41, Stuart Henderson wrote:
>
> On 2022/07/28 12:57, Scott Cheloha wrote:
>>> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>>>
>>> This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
>>> running the latest kernel from snaps.
>>
>> Defin
On 2022/07/28 12:57, Scott Cheloha wrote:
> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
> >
> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
> > running the latest kernel from snaps.
>
> Define "breaking".
That's clear from the output:
: On 2022/07/28 07
On Thursday, July 28th, 2022 at 4:55 AM, Dave Voutila wrote:
> This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
> running the latest kernel from snaps. sysctl entries immediately after
> boot:
>
> $ sysctl -a | grep tsc
> kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1
On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > Hi,
> >
> > Thanks to everyone who tested v3.
> >
> > Attached is v4. I would like to put this into snaps (bcc: deraadt@).
> >
> > If you've been following along and testing these patches, feel free to
Scott Cheloha writes:
> Hi,
>
> Thanks to everyone who tested v3.
>
> Attached is v4. I would like to put this into snaps (bcc: deraadt@).
>
> If you've been following along and testing these patches, feel free to
> continue testing. If your results change from v3 to v4, please reply
> with w
Hi,
Thanks to everyone who tested v3.
Attached is v4. I would like to put this into snaps (bcc: deraadt@).
If you've been following along and testing these patches, feel free to
continue testing. If your results change from v3 to v4, please reply
with what happened and your dmesg.
I made a fe
Hi,
>> On Jul 20, 2022, at 01:48, Masato Asou wrote:
>>
>> Sorry, my latest reply.
>>
>> I tested your patch on my Proxmox Virtual Environment on Ryzen7 box.
>> It works fine for me.
>
> This VM doesn't have the ITSC CPU flag,
> how is it using the TSC as a timecounter?
>
>> OpenBSD 7.1-curr
> On Jul 20, 2022, at 01:48, Masato Asou wrote:
>
> Sorry, my latest reply.
>
> I tested your patch on my Proxmox Virtual Environment on Ryzen7 box.
> It works fine for me.
This VM doesn't have the ITSC CPU flag,
how is it using the TSC as a timecounter?
> OpenBSD 7.1-current (GENERIC.MP) #1:
Sorry, my latest reply.
I tested your patch on my Proxmox Virtual Environment on Ryzen7 box.
It works fine for me.
OpenBSD 7.1-current (GENERIC.MP) #1: Wed Jul 20 14:15:23 JST 2022
a...@pve-obsd.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17162952704 (16367MB)
avail mem =
Christian Weisgerber wrote:
> Scott Cheloha:
>
> > > kern.timecounter.tick=1
> > > kern.timecounter.timestepwarnings=0
> > > kern.timecounter.hardware=i8254
> > > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000)
> > > acpitimer0(1000)
> >
> > This is expected behavior with the patch
Hi,
I tested your patch on my OpenSUSE + Xen on Ryzen7 box.
It works fine for me.
OpenBSD 7.1-current (GENERIC.MP) #1: Thu Jul 7 15:22:32 JST 2022
a...@xen-obsd1.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8556376064 (8159MB)
avail mem = 8279695360 (7896MB)
random: good s
On Thu, 07 Jul 2022 14:02:35 +0900 (JST)
YASUOKA Masahiko wrote:
> Hello Scott,
>
> With the patch, my machine on ESXi it doesn't show any extra message.
>
> *Without* the patch, the machine shows
>
> % grep 'TSC.*skew' dmesg.current-tsc-debug
> cpu1: disabling user TSC (skew=-2603)
> cpu2:
Hello Scott,
With the patch, my machine on ESXi it doesn't show any extra message.
*Without* the patch, the machine shows
% grep 'TSC.*skew' dmesg.current-tsc-debug
cpu1: disabling user TSC (skew=-2603)
cpu2: disabling user TSC (skew=-2959)
cpu3: disabling user TSC (skew=-3784)
%
and mono
On 7/7/22 11:29, Scott Cheloha wrote:
On Thu, Jul 07, 2022 at 11:13:14AM +0900, Yuichiro NAITO wrote:
I had another try for the v3 patch that runs on FreeBSD bhyve.
In this case, I need the following patch for TSC to be chosen as a timecounter.
diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/ar
On Thu, Jul 07, 2022 at 11:13:14AM +0900, Yuichiro NAITO wrote:
> I had another try for the v3 patch that runs on FreeBSD bhyve.
> In this case, I need the following patch for TSC to be chosen as a
> timecounter.
>
> diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> index c4d
I had another try for the v3 patch that runs on FreeBSD bhyve.
In this case, I need the following patch for TSC to be chosen as a timecounter.
diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
index c4d3acda8c7..ab34df4463c 100644
--- a/sys/arch/amd64/amd64/tsc.c
+++ b/sys/arch
On Wed, Jul 06, 2022 at 01:58:51PM -0700, Mike Larkin wrote:
> On Wed, Jul 06, 2022 at 11:48:41AM -0500, Scott Cheloha wrote:
> > > On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
> > >
> > > On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> > >> On Tue, Jul 05, 2022 at 01:38:32PM -
On Wed, Jul 06, 2022 at 08:20:05PM -0400, Mohamed Aslan wrote:
> > First, you need to update to the latest firmware. Maybe they already
> > fixed the problem. I don't see any mention of the TSC in the BIOS
> > changelog for the e495 but maybe you'll get lucky.
> >
> > Second, if they haven't fix
> First, you need to update to the latest firmware. Maybe they already
> fixed the problem. I don't see any mention of the TSC in the BIOS
> changelog for the e495 but maybe you'll get lucky.
>
> Second, if they haven't fixed the problem with the latest firmware, I
> recommend you reach out to L
On Wed, Jul 06, 2022 at 11:48:41AM -0500, Scott Cheloha wrote:
> > On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
> >
> > On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> >> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
> >>> On Mon, Jul 04, 2022 at 09:06:55PM -0500
> On Jul 6, 2022, at 10:04 AM, Christian Weisgerber wrote:
>
> Scott Cheloha:
>
>>> kern.timecounter.tick=1
>>> kern.timecounter.timestepwarnings=0
>>> kern.timecounter.hardware=i8254
>>> kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>>
>> This is expected behavio
> On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote:
>
> On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
>> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
>>> On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
[...]
>>>
>>> Here's the output from
On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote:
> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
> > On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> >
> > Here's the output from a 4 socket 80 thread machine.
>
> Oh nice. I think this
On Wed, Jul 06, 2022 at 01:48:39AM -0400, Mohamed Aslan wrote:
> > This is expected behavior with the patch.
> >
> > cpu0's TSC is way out of sync with every
> > other CPU's TSC, so the TSC is marked
> > as a bad timecounter and a different one is
> > chosen.
>
> Yes, I can see. Just want to add
Scott Cheloha:
> > kern.timecounter.tick=1
> > kern.timecounter.timestepwarnings=0
> > kern.timecounter.hardware=i8254
> > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>
> This is expected behavior with the patch.
>
> cpu0's TSC is way out of sync with every
> oth
> This is expected behavior with the patch.
>
> cpu0's TSC is way out of sync with every
> other CPU's TSC, so the TSC is marked
> as a bad timecounter and a different one is
> chosen.
Yes, I can see. Just want to add that without your latest patch the
kernel chooses the TSC as clocksource, howev
> On Jul 5, 2022, at 23:02, Mohamed Aslan wrote:
>
> Hi,
>
> Apologies. My bad, I applied the latest patch but booted into another
> kernel with an earlier patch!
>
> Here's what I got with your latest patch:
>
> $ dmesg | grep 'tsc'
> tsc: cpu0/cpu1: sync test round 1/2 failed
> tsc: cpu0/cp
Hi,
Apologies. My bad, I applied the latest patch but booted into another
kernel with an earlier patch!
Here's what I got with your latest patch:
$ dmesg | grep 'tsc'
tsc: cpu0/cpu1: sync test round 1/2 failed
tsc: cpu0/cpu1: cpu0: 40162 lags 5112675666 cycles
tsc: cpu0/cpu2: sync test round 1/2
Hi, Scotto.
I tested your patch on my Ryzen7 box.
And I got failed message:
tsc: cpu0/cpu1: sync test round 1/2 failed
tsc: cpu0/cpu1: cpu1: 1 lags 36 cycles
OpenBSD 7.1-current (GENERIC.MP) #3: Wed Jul 6 10:59:06 JST 2022
a...@g2-obsd.my.domain:/usr/src/sys/arch/amd64/compile/GENER
Sorry the `sysctl kern.timecounter` was before your patch.
Here's the one after your patch:
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=i8254
kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
On Tue,
What I meant in my first email is, it seems that before applying
your patch, the tsc was used as the hardware counter (no user TSC
though), but after applying your patch the i8254 was the one being
used.
Thanks
On Tue, Jul 05, 2022 at 10:34:54PM -0400, Mohamed Aslan wrote:
> Sorry the `sysctl ker
Hello,
I just tested your patch on my lenovo e495 laptop, unfortunately
still no tsc.
$ dmesg | grep 'tsc:'
tsc: cpu0/cpu1 sync round 1: 20468 regressions
tsc: cpu0/cpu1 sync round 1: cpu0 lags cpu1 by 5351060292 cycles
tsc: cpu0/cpu1 sync round 1: cpu1 lags cpu0 by 0 cycles
tsc: cpu0/cpu2 sync r
> On Jul 5, 2022, at 21:31, Mohamed Aslan wrote:
>
> Hello,
>
> I just tested your patch on my lenovo e495 laptop, unfortunately
> still no tsc.
>
> $ dmesg | grep 'tsc:'
> tsc: cpu0/cpu1 sync round 1: 20468 regressions
> tsc: cpu0/cpu1 sync round 1: cpu0 lags cpu1 by 5351060292 cycles
> tsc:
On Wed, Jul 06, 2022 at 09:14:03AM +0900, Yuichiro NAITO wrote:
> Hi, Scott.
>
> I tested your patch on my OpenBSD running on ESXi.
> It works fine for me and I never see monotonic clock going backward.
> There is nothing extra messages in my dmesg.
Great! Thanks for testing.
On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote:
> On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
> >
> > [...]
>
> Here's the output from a 4 socket 80 thread machine.
Oh nice. I think this is the biggest machine we've tried so far.
> kern.timecounter reports tsc a
Hi, Scott.
I tested your patch on my OpenBSD running on ESXi.
It works fine for me and I never see monotonic clock going backward.
There is nothing extra messages in my dmesg.
OpenBSD 7.1-current (GENERIC.MP) #27: Tue Jul 5 14:50:21 JST 2022
yuich...@yuichiro-obsd.soum.co.jp:/usr/src/sys/ar
On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote:
> Hi,
>
> Once again, I am trying to change our approach to TSC sync testing to
> eliminate false positive results. Instead of trying to repair the TSC
> by measuring skew, we just spin in a lockless loop looking for skew
> and mark th
On Tue, Jul 05, 2022 at 06:40:26PM +0200, Stuart Henderson wrote:
> On 2022/07/05 11:22, Scott Cheloha wrote:
> > On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> > > On 2022/07/04 21:06, Scott Cheloha wrote:
> > > > 4. OpenBSD VMs on other hypervisors.
> > >
> > > KVM on proxmo
On 2022/07/05 11:22, Scott Cheloha wrote:
> On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> > On 2022/07/04 21:06, Scott Cheloha wrote:
> > > 4. OpenBSD VMs on other hypervisors.
> >
> > KVM on proxmox VE 7.1-12
> >
> > I force acpihpet0 on this; it defaults to pvclock which r
On Tue, Jul 05, 2022 at 05:47:51PM +0200, Stuart Henderson wrote:
> On 2022/07/04 21:06, Scott Cheloha wrote:
> > 4. OpenBSD VMs on other hypervisors.
>
> KVM on proxmox VE 7.1-12
>
> I force acpihpet0 on this; it defaults to pvclock which results in
> timekeeping so bad that ntpd can't correct
On Tue, Jul 05, 2022 at 05:38:04PM +0200, Stuart Henderson wrote:
> On 2022/07/04 21:06, Scott Cheloha wrote:
> > 2. Other multisocket machines.
>
> This is from the R620 where I originally discovered the problems
> with SMP with the previous TSC test:
>
> $ dmesg|grep tsc
> $ sysctl kern.timecou
On Tue, Jul 05, 2022 at 10:53:43AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
> >>
> >> Scott Cheloha writes:
> >>
> >> > [...]
> >> >
> >> > If you fail the test you will see something like this:
> >> >
> >> > tsc:
On 2022/07/04 21:06, Scott Cheloha wrote:
> 4. OpenBSD VMs on other hypervisors.
KVM on proxmox VE 7.1-12
I force acpihpet0 on this; it defaults to pvclock which results in
timekeeping so bad that ntpd can't correct
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarni
On 2022/07/04 21:06, Scott Cheloha wrote:
> 2. Other multisocket machines.
This is from the R620 where I originally discovered the problems
with SMP with the previous TSC test:
$ dmesg|grep tsc
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.
Scott Cheloha writes:
> On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
>>
>> Scott Cheloha writes:
>>
>> > [...]
>> >
>> > If you fail the test you will see something like this:
>> >
>> >tsc: cpu0/cpu2: sync test round 1/2 failed
>> >tsc: cpu0/cpu2: cpu2: 13043 lags 438
On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
>
> Scott Cheloha writes:
>
> > [...]
> >
> > If you fail the test you will see something like this:
> >
> > tsc: cpu0/cpu2: sync test round 1/2 failed
> > tsc: cpu0/cpu2: cpu2: 13043 lags 438 cycles
> >
> > A printout like th
Scott Cheloha writes:
> Hi,
>
> Once again, I am trying to change our approach to TSC sync testing to
> eliminate false positive results. Instead of trying to repair the TSC
> by measuring skew, we just spin in a lockless loop looking for skew
> and mark the TSC as broken if we detect any.
>
>
Hi,
Once again, I am trying to change our approach to TSC sync testing to
eliminate false positive results. Instead of trying to repair the TSC
by measuring skew, we just spin in a lockless loop looking for skew
and mark the TSC as broken if we detect any.
This is motivated in part by some multi
Hi Scott, just installing on another 2-socket machine, could you
point me at the latest version of the TSC sync testing diff please?
On Wed, May 11, 2022 at 10:52:55AM +0900, Yuichiro NAITO wrote:
> Hi, Scott.
>
> Recently I started running OpenBSD on ESXi.
> I'm facing monotonic time going back problem as same as Yasuoka-san's report.
>
> https://marc.info/?l=openbsd-tech&m=161657532610882&w=2
>
> I've tried your v2 patch. I
Hi, Scott.
Recently I started running OpenBSD on ESXi.
I'm facing monotonic time going back problem as same as Yasuoka-san's report.
https://marc.info/?l=openbsd-tech&m=161657532610882&w=2
I've tried your v2 patch. It seems the problem has been solved in my enviroment.
But I'm a little bit conf
Scott Cheloha writes:
> Hi,
>
> Here is a second draft patch for changing our approach to TSC
> synchronization.
>
> With this patch, instead of trying to fix desync with a handshake we
> test for desync with a (more) foolproof loop and then don't attempt to
> correct for desync if we detect it
On 23.2.2022. 3:58, Scott Cheloha wrote:
> Please test! In particular:
>
> - I'd love retests on systems that failed the test using the previous
> patch. Almost all of these were AMD Ryzen CPUs. It's hard to say
> what the issue is there. My vague guess is a firmware bug.
>
> One would
Hi,
Here is a second draft patch for changing our approach to TSC
synchronization.
With this patch, instead of trying to fix desync with a handshake we
test for desync with a (more) foolproof loop and then don't attempt to
correct for desync if we detect it.
The motivation for a more foolproof l
Hello,
I can confirm the same behaviour with this patch applied.
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=i8254
kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
$ sysctl hw
hw.machine=amd64
hw.mode
Stuart Henderson writes:
> Thanks for testing.
>
> On 2022/02/02 13:51, Dave Voutila wrote:
>>
>> Jason McIntyre writes:
>>
>> > On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
>> >> This definitely wants testing on Ryzen ThinkPads (e.g.
>> >> E485/E585/X395/T495s)
>> >> or
> On Feb 2, 2022, at 13:29, Stuart Henderson wrote:
>
> Thanks for testing.
>
>> On 2022/02/02 13:51, Dave Voutila wrote:
>>
>> Jason McIntyre writes:
>>
>>> On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
This definitely wants testing on Ryzen ThinkPads (e.g.
E4
Thanks for testing.
On 2022/02/02 13:51, Dave Voutila wrote:
>
> Jason McIntyre writes:
>
> > On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
> >> This definitely wants testing on Ryzen ThinkPads (e.g.
> >> E485/E585/X395/T495s)
> >> or Inspiron 5505, I see user TSC disabled
Jason McIntyre writes:
> On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
>> This definitely wants testing on Ryzen ThinkPads (e.g. E485/E585/X395/T495s)
>> or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog.
>>
>>
>
> hi.
>
> here are the results from a 55
On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote:
> This definitely wants testing on Ryzen ThinkPads (e.g. E485/E585/X395/T495s)
> or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog.
>
>
hi.
here are the results from a 5505. was the timecounter meant to swit
This definitely wants testing on Ryzen ThinkPads (e.g. E485/E585/X395/T495s)
or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog.
On 2022/01/27 10:28, Scott Cheloha wrote:
> Hi,
>
> sthen@ complained recently about a multisocket system not being able
> to use the TSC in users
Hi,
sthen@ complained recently about a multisocket system not being able
to use the TSC in userspace because the sync test measured too much
skew and disabled it.
I don't think there is any real skew on that system. I think the sync
test is confusing NUMA overhead for skew and issuing a false po
86 matches
Mail list logo
