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
On Wed, 23 Feb 2022 00:04:07 +0100, Theo Buehler wrote:
> Hard to hit. Nevertheless it seems better to error out than to
> crash in strcmp()
Sure. OK millert@
- todd
Hard to hit. Nevertheless it seems better to error out than to
crash in strcmp()
Index: seq.c
===
RCS file: /cvs/src/usr.bin/seq/seq.c,v
retrieving revision 1.3
diff -u -p -r1.3 seq.c
--- seq.c 22 Feb 2022 16:14:38 -
On Tue, Feb 22, 2022 at 08:54:02PM +, Stuart Henderson wrote:
> On 2022/02/22 17:45, Jason McIntyre wrote:
> > On Tue, Feb 22, 2022 at 04:49:08PM +0100, Matthieu Herrb wrote:
> > > Hi,
> > >
> > > It looks to me that the -Y option is used to specify the destination
> > > to which to send
On 2022/02/22 17:45, Jason McIntyre wrote:
> On Tue, Feb 22, 2022 at 04:49:08PM +0100, Matthieu Herrb wrote:
> > Hi,
> >
> > It looks to me that the -Y option is used to specify the destination
> > to which to send synchronisation messages (not where to receive them,
> > this is -y).
> >
>
>
On Tue, Feb 22, 2022 at 07:04:23PM +0100, Mark Kettenis wrote:
> > Date: Tue, 22 Feb 2022 17:45:26 +
> > From: Visa Hankala
> >
> > On Tue, Feb 22, 2022 at 06:13:54PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 22 Feb 2022 16:59:24 +
> > > > From: Visa Hankala
> > > >
> > > > On
> Date: Tue, 22 Feb 2022 17:45:26 +
> From: Visa Hankala
>
> On Tue, Feb 22, 2022 at 06:13:54PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 22 Feb 2022 16:59:24 +
> > > From: Visa Hankala
> > >
> > > On Tue, Feb 22, 2022 at 05:31:31PM +0100, Mark Kettenis wrote:
> > > > > Date: Tue,
On Tue, Feb 22, 2022 at 06:13:54PM +0100, Mark Kettenis wrote:
> > Date: Tue, 22 Feb 2022 16:59:24 +
> > From: Visa Hankala
> >
> > On Tue, Feb 22, 2022 at 05:31:31PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 22 Feb 2022 15:58:31 +
> > > > From: Visa Hankala
> > > >
> > > > The
On Tue, Feb 22, 2022 at 04:49:08PM +0100, Matthieu Herrb wrote:
> Hi,
>
> It looks to me that the -Y option is used to specify the destination
> to which to send synchronisation messages (not where to receive them,
> this is -y).
>
hi.
i've never used -Yy so may be wrong, but i think the text
On Tue, Feb 22, 2022 at 06:00:34PM +0100, Claudio Jeker wrote:
> In the big conversion I forgot to include parse.y in the files.
> This diff fixes that.
Seems your sed missed a 'g' after the pattern :)
I believe all the variables you missed are visible below (mentioned
inline), with those fixed
> Date: Tue, 22 Feb 2022 16:59:24 +
> From: Visa Hankala
>
> On Tue, Feb 22, 2022 at 05:31:31PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 22 Feb 2022 15:58:31 +
> > > From: Visa Hankala
> > >
> > > The standard RISC-V calling convention says that the stack pointer
> > > should be
In the big conversion I forgot to include parse.y in the files.
This diff fixes that.
--
:wq Claudio
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.420
diff -u -p -r1.420 parse.y
--- parse.y
On Tue, Feb 22, 2022 at 05:31:31PM +0100, Mark Kettenis wrote:
> > Date: Tue, 22 Feb 2022 15:58:31 +
> > From: Visa Hankala
> >
> > The standard RISC-V calling convention says that the stack pointer
> > should be 16-byte aligned.
> >
> > The patch below corrects the alignment of the kernel
Sometimes (mainly for tests) it can be useful to run bgpd on something
different than port 179. The following diff does mostly that. It allows
to define a port with 'listen on' and makes it possible to set the port
on a neighbor like it is done for rtr sessions.
The only thing not working are
On Mon, Feb 21, 2022 at 9:47 PM David Gwynne wrote:
> this lets ifconfig show the MTU on interfaces like nvgre, vxlan, etc.
> they currently don't show it because they also implement a bridge ioctl,
> so ifconfig thinks they're a bridge.
>
> why ifconfig hides the mtu on bridges looks to be a
> Date: Tue, 22 Feb 2022 15:58:31 +
> From: Visa Hankala
>
> The standard RISC-V calling convention says that the stack pointer
> should be 16-byte aligned.
>
> The patch below corrects the alignment of the kernel stack in context
> switching and exception handling.
>
> OK?
Is there a
The standard RISC-V calling convention says that the stack pointer
should be 16-byte aligned.
The patch below corrects the alignment of the kernel stack in context
switching and exception handling.
OK?
The diff reveals that curcpu is stored in an unnamed spot near the upper
end of u-area when
Hi,
It looks to me that the -Y option is used to specify the destination
to which to send synchronisation messages (not where to receive them,
this is -y).
Index: dhcpd.8
===
RCS file: /cvs/OpenBSD/src/usr.sbin/dhcpd/dhcpd.8,v
On Tue, Feb 22, 2022 at 02:01:26PM +0100, Theo Buehler wrote:
> EVP_PKEY_set1_EC_KEY() bumps eckey's refcount (that's what "set1" means),
> so eckey isn't freed when pkey is freed at the end of keyproc() or
> acctproc() (which means that secret data isn't wiped). Moving the
> freeing of eckey to
EVP_PKEY_set1_EC_KEY() bumps eckey's refcount (that's what "set1" means),
so eckey isn't freed when pkey is freed at the end of keyproc() or
acctproc() (which means that secret data isn't wiped). Moving the
freeing of eckey to the end of ec_key_create() decrements the refcount
again which should
OK florian
Start of forwarded message
From: Wolf
To: m...@openbsd.org
Cc: Wolf
Subject: [PATCH] Move warnx into correct place
Date: Sun, 20 Feb 2022 15:10:16 +0100
Original location caused the line to be printed every time for ec keys.
I suspect copy
On Tue, Feb 22, 2022 at 03:46:05PM +1000, David Gwynne wrote:
> this lets ifconfig show the MTU on interfaces like nvgre, vxlan, etc.
> they currently don't show it because they also implement a bridge ioctl,
> so ifconfig thinks they're a bridge.
>
> why ifconfig hides the mtu on bridges looks
22 matches
Mail list logo
