Hi Otto,
On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote:
> Although I'm not terribly interested in bugs that are only seen (s0
> far) using emulation, please send me the details on how you set up
> qemu.
Right, it could very well be a TCG bug. But maybe not. Here's how to
get things
On Wed, 27 May 2020 01:43:34 -0600
"Jason A. Donenfeld" wrote:
> On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot
> wrote:
> > First question is, is it possible to use the wg(4) interface
> > without a port?
>
> No, that is not how WireGuard works. For details on the actual
> protocol
pipex(4) is simultaneously protected by KERNEL_LOCK() and NET_LOCK() and
the last is not required. I guess to start remove NET_LOCK(). Diff below
drops NET_LOCK() in pipex_ioctl() and underlaying routines. At least
this helps to kill unlock/lock mess in pppx_add_session() and
pppx_if_destroy().
> Date: Wed, 27 May 2020 19:39:07 +1000
> From: Jonathan Gray
>
> When testing the row and column increase for efifb on a 1920x1080
> display I noticed the top part of the screen continues to contain part
> of a white on blue line from earlier in the dmesg even after the machine
> has finished
When these two syscalls have been marked NOLOCK, falloc(), fdinsert() &
friends weren't ready to be executed without KERNEL_LOCK(). This is no
longer true. kqueue(2), for example, do the same dances without this
lock.
ok?
Index: kern/uipc_syscalls.c
On Wed, 27 May 2020 09:34:53 +0200
Martin Pieuchot wrote:
> Hello Matt,
>
> Thank you for your submission.
Hi Martin,
No worries, thank you for your feedback. This is something I want to
help make happen and if I recall correctly, someone once said that if I
wanted a new feature on OpenBSD
On Wed, May 27, 2020 at 03:14:29AM -0600, Jason A. Donenfeld wrote:
> One interesting quirk in doing this on qemu is that the 6.7 and
> -current kernel both crash:
>
> Loading FCode image...
> Loaded 6882 bytes
> entry point is 0x4000
> Evaluating FCode...
> OpenBSD IEEE 1275 Bootblock 2.0
>
When testing the row and column increase for efifb on a 1920x1080
display I noticed the top part of the screen continues to contain part
of a white on blue line from earlier in the dmesg even after the machine
has finished booting.
RI_CENTER changes the ri_bits offset, doing RI_CLEARMARGINS in
On Wed, May 27, 2020 at 2:12 AM Jason A. Donenfeld wrote:
>
> Hi again Klemens,
>
> On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote:
> >
> > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> > > With regards to your crash, though, that's a bit more puzzling, and
> > > I'd be
Hey David,
On Wed, May 27, 2020 at 2:26 AM David Gwynne wrote:
>
> On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote:
> > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> > > With regards to your crash, though, that's a bit more puzzling, and
> > > I'd be interested
On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote:
> On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> > With regards to your crash, though, that's a bit more puzzling, and
> > I'd be interested to learn more details. Because these structs are
> > already naturally
Hi again Klemens,
On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote:
>
> On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> > With regards to your crash, though, that's a bit more puzzling, and
> > I'd be interested to learn more details. Because these structs are
> > already
On Tue, 26 May 2020 13:28:22 +0200
Tobias Heider wrote:
> Hi Matt,
>
> just repeating what I commented yesterday for the new diff to make
> sure it isn't overlooked.
Thank you for repeating it, I didn't get around to addressing it before
the new diff.
> > +int
> > +wg_ioctl_get(struct
Hi Martin,
To answer a few but not all of your questions:
On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot wrote:
> First question is, is it possible to use the wg(4) interface without a
> port?
No, that is not how WireGuard works. For details on the actual
protocol particulars, please see
Hello Matt,
Thank you for your submission.
On 26/05/20(Tue) 19:39, Matt Dunwoodie wrote:
> After some feedback and comments, we've addressed the concerns, and
> fixed a few things from our side too. Overall the structure is familiar
> with no major changes, so any prior readings mostly carry
On 26/05/20(Tue) 10:31, Claudio Jeker wrote:
> [...]
> npppd(8) is server only it can not establish a connection. pppd(8) on the
> other hand is more client side (but I think it can do both).
Could someone knowledgable indicate that in the man pages? Currently
there is:
npppd – new
16 matches
Mail list logo
