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 hold over from when
brconfig was merged into ifconfig. if we dont
"Todd C. Miller" writes:
> On Sun, 13 Feb 2022 12:07:31 -0800, Greg Steuck wrote:
>
>> I noticed that despite the OKs the code didn't submitted. Should we
>> revive this diff now and continue in the tree?
>>
>> I have vested interest: I don't want to fix up lang/ghc test suite which
>> is full
> Date: Mon, 21 Feb 2022 17:34:14 +
> From: Visa Hankala
>
> On riscv64, ddb's stack unwinder performs poorly. The main problem is
> that the exception handlers use a frame structure (trapframe) that
> differs from the typical call frame.
>
> The following patch does several adjustments,
Errata patches for slaacd have been released for OpenBSD 6.9 and 7.0.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
> Date: Mon, 21 Feb 2022 17:37:22 +
> From: Visa Hankala
>
> When setting up the stack for a (kernel) thread on riscv64, zero the
> frame pointer in switchframe so that the frame chain terminates cleanly.
> At the moment, the unwinding of kernel thread stacks stops to "bad frame
> pointer"
On Sun, 13 Feb 2022 12:07:31 -0800, Greg Steuck wrote:
> I noticed that despite the OKs the code didn't submitted. Should we
> revive this diff now and continue in the tree?
>
> I have vested interest: I don't want to fix up lang/ghc test suite which
> is full of seq(1).
Here's an updated diff
When setting up the stack for a (kernel) thread on riscv64, zero the
frame pointer in switchframe so that the frame chain terminates cleanly.
At the moment, the unwinding of kernel thread stacks stops to "bad frame
pointer" error.
OK?
Index: arch/riscv64/riscv64/cpuswitch.S
On riscv64, ddb's stack unwinder performs poorly. The main problem is
that the exception handlers use a frame structure (trapframe) that
differs from the typical call frame.
The following patch does several adjustments, including:
* Detect and handle exception frames. (Alternatively, the
Stefan Sperling wrote:
> Pledge and unveil interfering with profiling is a separate issue which
> is more obvious when it occurs and can easily be worked around by the
> developer.
Basically any privsep method or technology will harm accounting, because
accounting file access makes a poor path
On Mon, Feb 21, 2022 at 10:20:17AM +0100, Marc Espie wrote:
> On Mon, Feb 21, 2022 at 05:36:16PM +0900, Yuichiro NAITO wrote:
> > Of course, all programs compiled without '-pg' work fine for me.
> > I found this issue when I profile my application with gprof(1).
> > For example, following example
On Mon, Feb 21, 2022 at 05:36:16PM +0900, Yuichiro NAITO wrote:
> Of course, all programs compiled without '-pg' work fine for me.
> I found this issue when I profile my application with gprof(1).
> For example, following example C source code fails to execute on OpenBSD 7.0.
Profile is partly
Of course, all programs compiled without '-pg' work fine for me.
I found this issue when I profile my application with gprof(1).
For example, following example C source code fails to execute on OpenBSD 7.0.
```
$ cat helloworld.c
#include
int main(int argc, char *argv[])
{
printf("Hello
12 matches
Mail list logo
