Re: panic: System call old.recv returning with 1 locks held

On Sun, Sep 10, 2006 at 07:45:36PM +0200, Alexander Leidinger wrote:
> Hi,
> 
> while running the Linux Test Project (ltp.sf.net) testsuite to check
> for bugs in our linuxolator, I got the panic mentioned in the subject.
> 
> LTP was executing the semop5 testcase.
> 
> The kernel dump doesn't look as if it is helpful:
> ---snip---
> Unread portion of the kernel message buffer:
> panic: System call old.recv returning with 1 locks held
> Uptime: 3h51m44s
> Physical memory: 503 MB
> Dumping 101 MB: 86 70 54 (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  38 (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  22 6
> 
> #0  doadump () at pcpu.h:166
> 166             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) kldsyms
> add symbol table from file
> "/big/usr/src/sys/i386/compile/WORK/modules/big/usr/src/sys/modules/accf_data/accf_data.ko.debug"
> at .text_addr = 0xc078e498
> [...]
> add symbol table from file
> "/big/usr/src/sys/i386/compile/WORK/modules/big/usr/src/sys/modules/sysvipc/sysvmsg/sysvmsg.ko.debug"
> at .text_addr = 0xc07e33dc .data_addr = 0xc07e5900
>         .bss_addr = 0xc07e5e88
> add symbol table from file
> "/big/usr/src/sys/i386/compile/WORK/modules/big/usr/src/sys/modules/sysvipc/sysvsem/sysvsem.ko.debug"
> at .text_addr = 0xc07e9790 .data_addr = 0xc07ec280
>         .bss_addr = 0xc07ec8a4
> add symbol table from file
> "/big/usr/src/sys/i386/compile/WORK/modules/big/usr/src/sys/modules/sysvipc/sysvshm/sysvshm.ko.debug"
> at .text_addr = 0xc07ef4dc .data_addr = 0xc07f16a0
>         .bss_addr = 0xc07f1c6c
> [...]
> add symbol table from file
> "/big/usr/src/sys/i386/compile/WORK/modules/big/usr/src/sys/modules/linux/linux.ko.debug"
> at .text_addr = 0xc2a2b248 .data_addr = 0xc2a3b000
>         .bss_addr = 0xc2a3d780
> [...]
> (kgdb) bt
> #0  doadump () at pcpu.h:166
> During symbol reading, Incomplete CFI data; unspecified registers at
> 0xc04945a2.#1  0xc0494c72 in boot (howto=0x104)
> at ../../../kern/kern_shutdown.c:409 #2  0xc04947c1 in panic
> (fmt=0xc05c43b9 "System call %s returning with %d locks held")
> at ../../../kern/kern_shutdown.c:565 #3  0xc0588f7b in syscall (frame=
> {tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0x3b, tf_edi = 0x28060ca0, tf_esi
> = 0x0, tf_ebp = 0xbfbfea28, tf_isp = 0xd5b4ed64, tf_ebx = 0x9, tf_edx =
> 0x2817bff4, tf_ecx = 0xbfbfea00, tf_eax = 0xffffffa6, tf_trapno = 0xc,
> tf_err = 0x2, tf_eip = 0x28120706, tf_cs = 0x33, tf_eflags = 0x247,
> tf_esp = 0xbfbfe9fc, tf_ss = 0x3b}) at ../../../i386/i386/trap.c:1060
> #4  0xc057a7ff in Xint0x80_syscall ()
> at ../../../i386/i386/exception.s:191 #5  0x00000033 in ?? () Previous
> frame inner to this frame (corrupt stack?)
> ---snip---
> 
> Any ideas how to get more helpful info out of this?

Enable DEBUG_LOCKS and DEBUG_VFS_LOCKS then run 'show lockedvnods'
from DDB to find out where the lockmgr lock was acquired.

Kris