Hi Andriy, Could you by any chance provide a bit more info on the system networking configuration and the steps leading to panic? No chance for a coredump?
destroy_nhgrp() suggests that there was a multipath route (default?) that was deleted. nhops are created with UMA_ALIGN_PTR, so I suspect there is a garbage inside nhgrp pointer.. > On 22 Jun 2021, at 11:31, Andriy Gapon <a...@freebsd.org> wrote: > > > It seems that the panic message was > panic: Misaligned access from kernel space! > > On 22/06/2021 12:54, Andriy Gapon wrote: >> Not sure if I'll be able to get more out of this arm64 machine. >> I was playing with ppp and switching routes between LAN and ppp when the >> crash happened. >> The system is 2-3 weeks old 14.0-CURRENT as of c8250c5ada85fec. >> Tracing pid 0 tid 100014 td 0xffffa00000c00000 >> db_trace_self() at db_trace_self >> db_stack_trace() at db_stack_trace+0x11c >> db_command() at db_command+0x244 >> db_command_loop() at db_command_loop+0x54 >> db_trap() at db_trap+0xf8 >> kdb_trap() at kdb_trap+0x1c4 >> handle_el1h_sync() at handle_el1h_sync+0x74 >> --- exception, esr 0xf2000000 >> kdb_enter() at kdb_enter+0x44 >> vpanic() at vpanic+0x1c4 >> panic() at panic+0x44 >> align_abort() at align_abort+0xb8 >> handle_el1h_sync() at handle_el1h_sync+0x74 >> --- exception, esr 0x96000021 >> nhop_free() at nhop_free+0x100 >> destroy_nhgrp() at destroy_nhgrp+0x38 >> epoch_call_task() at epoch_call_task+0x158 >> gtaskqueue_run_locked() at gtaskqueue_run_locked+0x178 >> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x9c >> fork_exit() at fork_exit+0x74 >> fork_trampoline() at fork_trampoline+0x14 > > > -- > Andriy Gapon >
