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>
