On Mon, Jan 19, 2026 at 09:29:34PM +0000, Klemens Nanni wrote:
> 19.01.2026 22:55, Miod Vallat пишет:
> >> Nothing besides nd6 spam (about addresses of non-OpenBSD devices that work
> >> just fine):
> >>
> >> ddb{0}> dmesg
> >> <7>nd6_resolve: xxxx:xxxx:xxxx:xxxx:397f:4b51:7bcb:c6ff: incorrect nd6
> >> information
> >> ...
> >> Trap cause = 2 Frame 0x980000000fd97878
> >> Trap PC 0xffffffff8119dbdc RA 0xffffffff8119df2c fault 0x0
> >
> > This is a NULL pointer dereference happening at 0xffffffff8119dbdc. If
> > you x/i 0xffffffff8119dbdc this will show you where in cnmac_recv_mbuf
> > this happens, and then we can figure out the corresponding line in
> > if_cnmac.c.
>
> x/i gives the same address from my previous mail:
>
> >> Stopped at cnmac_recv_mbuf+0x134: ld v1,32(t8)
>
> I tried this:
>
> router# objdump -d /bsd | grep -m1 cnmac_recv_mbuf
> ffffffff8119daa8 <cnmac_recv_mbuf>:
> router# addr2line -e/bsd $(python3
> -c'print(hex(0xffffffff8119daa8+0x134))')
> ??:0
>
> Then against a fresh COPTS=-O0 DEBUG=-g kernel, but same result, also with:
>
> builder# egdb -q -batch -ex 'info line *cnmac_recv_mbuf+0x134' obj/bsd
>
> No line number information available for address 0xffffffff814954e4
> <cnmac_recv_mbuf+308>
obj/bsd.gdb for line numbers
