On Mon, Aug 14, 2023 at 02:07:12AM +, Jason Tubnor wrote:
>> Hi,
> Not sure how this can happen. Have you destroyed and recreated the interface
> in between? Can you easily reproduce this?
No I didn't it just seem to drop. It happened twice yesterday but I have, even
under continous load,
Klemens Nanni wrote:
> @@ -1117,13 +1117,6 @@ bio_changepass(char *dev)
>
> /* Current passphrase. */
> bio_kdf_derive(, , "Old passphrase: ", 0);
> -
> - /*
> - * Unless otherwise specified, keep the previous number of rounds as
> - * long as we're using the same KDF.
On Sun, Aug 13, 2023 at 10:02:26PM -0700, Kevin Williams wrote:
> What about giving sysupgrade the same verbosity options as fw_update?
> This would mean -v and -vv I sysupgrade would pass through the same
> options to fw_update.
>
> And for the installer, maybe another question: “Verbose download
On Sun, Aug 13, 2023 at 05:58:01PM -0700, Philip Guenther wrote:
> I think that changing the behavior of the existing API in a way that
> gratuitously increases the differences between BSDs is unwise. IMHO, we
> should follow NetBSD on this and add kqueue1(), that being obviously
> consistent
On Mon, Aug 14, 2023 at 02:07:12AM +, Jason Tubnor wrote:
> Hi,
>
> Testing sec(4) between 2 end points with iperf3, iked has lost the associated
> iface for the sec(4) point to point link. Specifically:
>
> pfkey_sa: unsupported interface
Not sure how this can happen. Have you destroyed
On Mon, Aug 14, 2023 at 06:24:14PM +1000, Jonathan Matthew wrote:
> On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> > This is the next patch in the clock interrupt reorganization series.
> >
> > Before we continue breaking up the hardclock(9) we need to detour into
> > the MD
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> This is the next patch in the clock interrupt reorganization series.
>
> Before we continue breaking up the hardclock(9) we need to detour into
> the MD code.
>
> This patch divides the "initialization" parts of cpu_initclocks()
On Fri, Aug 11, 2023 at 05:38:41PM +0200, Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > I think this case is different, because the ramdisk has no process
> > contention.
> >
> > The code still sticks to minimum 16:
> >
> > if (r < 16)
> > r = 16;
> >
> > On faster
