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
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,
> > > >
> > > >
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
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.
>
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
> > 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
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
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
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
> 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:
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
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
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
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.
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
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
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,
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
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
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
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
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
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 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 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
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
On Sat, Jul 02, 2022 at 02:12:56PM +, Visa Hankala wrote:
> Remove the leftovers of the old poll/select mechanism.
> This includes the fields si_seltid and si_flags in struct selinfo.
> They should now always be zero because nothing calls selrecord().
>
> selwakeup() becomes a wrapper for
> On Jul 5, 2022, at 1:51 AM, Otto Moerbeek wrote:
>
> On Mon, Jul 04, 2022 at 05:44:33PM -0400, Daniel Dickman wrote:
>
>>
>>
>>> On Sun, 3 Jul 2022, Daniel Dickman wrote:
>>>
>>> On Sat, Jul 2, 2022 at 9:26 PM Ben Fuller wrote:
I noticed Montenegro doesn't have an entry.
> 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:
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
> 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,
32 matches
Mail list logo
