Re: Kernel panic for if_epair

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