> 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 Thu, Jun 23, 2022 at 09:58:48PM -0500, Scott Cheloha wrote:
>
> [...]
>
> Thoughts? Tweaks?
>
> [...]
miod: Any issues?
kettenis: Anything to add? ok?
drahn: Anything to add? ok?
--
It would be nice (but not strictly necessary) to test this on a
machine doing "real work".
Who does
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
This is something I added in 2011 (I think) to bsd.port.subdir.mk
if FULLPATH=Yes, a FULLPKGPATH like
SUBDIR=cat/location
will give you the EMPTY flavor for that location instead of the DEFAULT flavor.
I'm now questionning whether this actually makes senses considering the changes
I was making at
pppoe_timeout() and pppoe_clone_destroy() are both executed with kernel
lock held, but they are not serialized because pppoe_timeout() has the
sleep point provided by netlock. We should use timeout_del_barrier(9) to
ensure pppoe_timeout() finished. Also pppoe_timeout() could be
rescheduled if the i
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 11:53:26AM +0200, Claudio Jeker wrote:
> On Tue, Jul 05, 2022 at 11:34:21AM +, Job Snijders wrote:
> > On Tue, Jul 05, 2022 at 11:08:13AM +0200, Claudio Jeker wrote:
> > > On Mon, Jul 04, 2022 at 05:10:05PM -0500, Scott Cheloha wrote:
> > > > On Mon, Jul 04, 2022 at 11:1
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.
>
>
> > this changeset too.
>
> Ah right, we print us not ms.
>
> > nitpick: the changeset doesn't apply cleanly:
>
> Forgot to update that tree :)
>
> Updated diff below
OK job@
On Tue, Jul 05, 2022 at 11:34:21AM +, Job Snijders wrote:
> On Tue, Jul 05, 2022 at 11:08:13AM +0200, Claudio Jeker wrote:
> > On Mon, Jul 04, 2022 at 05:10:05PM -0500, Scott Cheloha wrote:
> > > On Mon, Jul 04, 2022 at 11:15:24PM +0200, Claudio Jeker wrote:
> > > > On Mon, Jul 04, 2022 at 01:2
On Tue, Jul 05, 2022 at 11:08:13AM +0200, Claudio Jeker wrote:
> On Mon, Jul 04, 2022 at 05:10:05PM -0500, Scott Cheloha wrote:
> > On Mon, Jul 04, 2022 at 11:15:24PM +0200, Claudio Jeker wrote:
> > > On Mon, Jul 04, 2022 at 01:28:12PM -0500, Scott Cheloha wrote:
> > > > Hi,
> > > >
> > > > Couple
On Mon, Jul 04, 2022 at 05:10:05PM -0500, Scott Cheloha wrote:
> On Mon, Jul 04, 2022 at 11:15:24PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 04, 2022 at 01:28:12PM -0500, Scott Cheloha wrote:
> > > Hi,
> > >
> > > Couple things:
> > >
> > > [...]
> >
> > I don't like the introduction of all t
30 matches
Mail list logo
