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

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?

Bye,
Alexander.

-- 
"man hier" will explain the way FreeBSD filesystems are normally laid out.
		-- David Scheidt <dscheidt_at_tumbolia.com>
http://www.Leidinger.net  Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild _at_ FreeBSD.org  : PGP ID = 72077137