> On 19 May 2022, at 07:26, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote: > > I managed to capture the full console output this time: > > Fatal data abort: > x0: 0 > x1: 6 > x2: 0 > x3: 0 > x4: 0 > x5: ffffa000beeb9b98 > x6: ff > x7: ffffa00000c2e100 > x8: ffffa000b79305a8 > x9: 0 > x10: 20000 > x11: 0 > x12: 0 > x13: 0 > x14: ffffa00000ce3700 > x15: 0 > x16: ffff0000e5cbfff8 (_DYNAMIC + 4a0) > x17: ffff000000589828 (sosend + 0) > x18: ffff0000e6707490 (ratelimit_v6 + a37280) > x19: 0 > x20: ffff0000e6707518 (ratelimit_v6 + a37308) > x21: 0 > x22: 0 > x23: 14 > x24: 40 > x25: ffff0000e6707538 (ratelimit_v6 + a37328) > x26: 0 > x27: 0 > x28: ffffa00081055d3c > x29: ffff0000e6707490 (ratelimit_v6 + a37280) > sp: ffff0000e6707490 > lr: ffff000000657724 (fib4_lookup + 40) > elr: 0 > spsr: 60000045 > far: 0 > esr: 86000004 > panic: vm_fault failed: 0 error 1 > cpuid = 4 > time = 1652940940 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2c4 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x86000004 > (null)() at 0 > ip_output() at ip_output+0x9a4 > udp_send() at udp_send+0xb5c > sosend_dgram() at sosend_dgram+0x4a4 > sosend() at sosend+0x2c > wg_send() at wg_send+0x108 > wg_deliver_out() at wg_deliver_out+0x17c > gtaskqueue_run_locked() at gtaskqueue_run_locked+0x17c > gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x130 > fork_exit() at fork_exit+0x88 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 0 tid 100280 ] > Stopped at kdb_enter+0x40: undefined f907827f > db>
This looks like the kernel is jumping to a NULL pointer. Looking at fib4_lookup + 40 on a recent kernel leads me to believe the issue is likely due to dp->f being invalid. Andrew
