Michael van Elst a écrit : > joel.bertrand%systella.fr@localhost (=?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. Maybe. But this panic occurs around 06:00 AM. Hard locks often occur during night (between 02:00 and 07:00 AM). And I'm not sure that hard lock on my system is related to iscsi itself. Maybe iscsi support raises another locking problem.
Attachment:
signature.asc
Description: OpenPGP digital signature