joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: >[ 24082.528401] cpu4[3392 slave]: hogging kernel lock >[ 24082.528401] Kernel lock error: _kernel_lock,266: spinout
>[ 24082.528401] ipi_msg_cpu_handler() at netbsd:ipi_msg_cpu_handler+0x68 >[ 24082.528401] lock address : netbsd:kernel_lock >[ 24082.528401] type : spin >[ 24082.528401] initialized : netbsd:main+0x72 >[ 24082.528401] shared holds : 0 exclusive: > 1 >[ 24082.528401] shares wanted: 0 exclusive: > 5 >[ 24082.528401] relevant cpu : 2 last held: > 4 >[ 24082.528401] relevant lwp : 0xffffaceebb7ad6c0 last held: >0xffffaceec299d0c0 >[ 24082.528401] last locked* : netbsd:tcp_rcvd_wrapper+0x1a >[ 24082.528401] unlocked : netbsd:ipintr+0x1e7 >[ 24082.528401] curcpu holds : 0 wanted by: >0xffffaceebb7ad6c0 >[ 24082.528401] panic: LOCKDEBUG: Kernel lock error: _kernel_lock,266: >spinout That's a different kind of locking problem. Not sure what triggers this in your case, but it reminds me about the symptoms of a forwarding loop in the network stack. It's only visible with LOCKDEBUG as that adds a 10 second timeout to the kernel lock.
