> Date: Tue, 14 Jul 2020 20:17:30 -0500
> From: Scott Cheloha
> Cc: Mark Kettenis , tech@openbsd.org, p...@irofti.net
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> > On Tue, 14 Jul 2020 11:59:14 +02
> Date: Tue, 14 Jul 2020 20:21:24 -0400
> From: George Koehler
>
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the same since one
> > is always odd
On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the same since one
> > is always odd and
On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
Mark Kettenis wrote:
> Yeah, one possible approach would be to increment ogen by two. A
> little bit easier to check that they can never be the same since one
> is always odd and the other is always even.
>
> Another possible approach would be to export
On Tue, Jul 14, 2020 at 11:59:14AM +0200, Mark Kettenis wrote:
> > Date: Mon, 13 Jul 2020 17:07:31 -0400
> > From: George Koehler
> >
> > On Mon, 13 Jul 2020 01:18:14 -0500
> > Scott Cheloha wrote:
> >
> > > To review, the update protocol is:
> > >
> > > 1. Set tk_generation to zero; the updat
> Date: Mon, 13 Jul 2020 17:07:31 -0400
> From: George Koehler
>
> On Mon, 13 Jul 2020 01:18:14 -0500
> Scott Cheloha wrote:
>
> > To review, the update protocol is:
> >
> > 1. Set tk_generation to zero; the update has begun.
> >
> > 2. Memory barrier. The side effects of step (1) are "visib
On Mon, 13 Jul 2020 01:18:14 -0500
Scott Cheloha wrote:
> To review, the update protocol is:
>
> 1. Set tk_generation to zero; the update has begun.
>
> 2. Memory barrier. The side effects of step (1) are "visible" to
>other CPUs before those of step (3).
>
> 3. Update the other tk_* memb
On Mon, 13 Jul 2020 10:24:49 +0300
Paul Irofti wrote:
> I am assuming you tested on amd64. Mind sharing the dmesg? Could this be due
> to the lack of RDTSC serialization in userland?
I got the problem on my 4-core amd64 and on a 1-cpu macppc. Here's my
amd64 dmesg. In my next mail, I will des
Hi,
I am assuming you tested on amd64. Mind sharing the dmesg? Could this be due to
the lack of RDTSC serialization in userland?
Thank you for the report!
Paul
În 13 iulie 2020 06:44:57 EEST, George Koehler a scris:
>Hello tech list,
>
>My CLOCK_MONOTONIC can jump backwards. It looks like a
On Sun, Jul 12, 2020 at 11:44:57PM -0400, George Koehler wrote:
> Hello tech list,
>
> My CLOCK_MONOTONIC can jump backwards.
I can reproduce it here. Very unsettling.
> It looks like a problem with tk_generation in the user timekeep page.
> If tk_offset_count and tk_offset change but tk_gener
Hello tech list,
My CLOCK_MONOTONIC can jump backwards. It looks like a problem with
tk_generation in the user timekeep page. If tk_offset_count and
tk_offset change but tk_generation doesn't change, then libc can mix
old and new values and calculate a bogus time.
This diff tries to fix it. Th
11 matches
Mail list logo
