On 16 Feb 2022, at 11:31, qroxana wrote: > It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @ > /usr/src/sys/net/if_epair.c:165 > stack backtrace: > #0 0xc03558f8 at witness_debugger+0x7c > #1 0xc0356b3c at witness_warn+0x3fc > #2 0xc05eb3c8 at abort_handler+0x1d8 > #3 0xc05ca8e0 at exception_exit+0 > #4 0xc0475928 at udp_input+0x1c0 > #5 0xc0441884 at ip_input+0xa18 > #6 0xc041426c at netisr_dispatch_src+0x100 > #7 0xc040b9a0 at ether_demux+0x1c8 > #8 0xc040d22c at ether_nh_input+0x514 > #9 0xc041426c at netisr_dispatch_src+0x100 > #10 0xc040be94 at ether_input+0x8c > #11 0xe2fd8130 at $a.8+0x128 > #12 0xc02a1ee0 at ithread_loop+0x268 > #13 0xc029e088 at fork_exit+0xa0 > #14 0xc05ca870 at swi_exit+0 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xe2a0baf0 > FSR=00000001, FAR=e3f02a56, spsr=20000013 > r0 =00000000, r1 =00000001, r2 =00000001, r3 =00000a0a > r4 =00000000, r5 =e3f02a6a, r6 =e3f02a56, r7 =00000044 > r8 =00000044, r9 =c0af955c, r10=00000014, r11=e2a0bc10 > r12=00000000, ssp=e2a0bb80, slr=c0441884, pc =c0475928 > > panic: Fatal abort
That backtrace suggests an alignment fault in udp_input(), not an issue with if_epair. There’s not even any mention of if_epair in that backtrace, but I suppose it’s remotely possible that it’s in epair_intr(), calling epair_sintr() in #11. That would explain why the epair lock is held, at least. Note that the epair code has been substantially reworked recently so if you retry with a recent (post 24f0bfbad57b9c3cb9b543a60b2ba00e4812c286) build you won’t see the epair lock mentioned (assuming you can reproduce the panic), but again, it doesn’t look to be involved here anyway. Kristof
