Christian Brueffer
2005-Feb-08 17:08 UTC
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
I'm getting this reproducible panic with a 5-STABLE system based on
sources from yesterday. The machine in question is an i386 SMP box.
The panic is reproducible by running an updated version of the
security/scanssh port which is based on libevent.
A crashdump is available for further investigation.
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @
/usr/home/build/src/sys/net/bpf.c:1119
panic messages:
---
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @
/usr/home/build/src/sys/net/bpf.c:1119
cpuid = 1
KDB: enter: panic
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
doadump () at pcpu.h:159
159 in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc047fe25 in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xd8a60978 "??z?")
at /usr/home/build/src/sys/ddb/db_command.c:531
#2 0xc047fbb2 in db_command (last_cmdp=0xc07aeaa4, cmd_table=0x0,
aux_cmd_tablep=0xc0776ed0,
aux_cmd_tablep_end=0xc0776ed4) at
/usr/home/build/src/sys/ddb/db_command.c:349
#3 0xc047fcc5 in db_command_loop () at
/usr/home/build/src/sys/ddb/db_command.c:455
#4 0xc0481e05 in db_trap (type=3, code=0) at
/usr/home/build/src/sys/ddb/db_main.c:221
#5 0xc05837be in kdb_trap (type=0, code=0, tf=0x1) at
/usr/home/build/src/sys/kern/subr_kdb.c:418
#6 0xc070f0a8 in trap (frame {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi =
256, tf_esi = 1,
tf_ebp = -660206816, tf_isp = -660206844, tf_ebx = -660206756, tf_edx 0, tf_ecx
= -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip
= -1067961200, tf_cs = 8, tf_eflags = 646, tf_esp = -1066043284, tf_ss
-1066052328})
at /usr/home/build/src/sys/i386/i386/trap.c:576
#7 0xc06fa7ca in calltrap () at
/usr/home/build/src/sys/i386/i386/exception.s:140
#8 0x00000018 in ?? ()
#9 0x00000010 in ?? ()
#10 0x00000010 in ?? ()
#11 0x00000100 in ?? ()
#12 0x00000001 in ?? ()
#13 0xd8a60b20 in ?? ()
#14 0xd8a60b04 in ?? ()
#15 0xd8a60b5c in ?? ()
#16 0x00000000 in ?? ()
#17 0xc1033000 in ?? ()
#18 0x00000012 in ?? ()
#19 0x00000003 in ?? ()
#20 0x00000000 in ?? ()
#21 0xc0583490 in kdb_enter (msg=0x0) at cpufunc.h:56
#22 0xc0566aee in panic (fmt=0xc075490e "_mtx_lock_sleep: recursed on
non-recursive mutex %s @ %s:%d\n")
at /usr/home/build/src/sys/kern/kern_shutdown.c:550
#23 0xc055c914 in _mtx_lock_sleep (m=0xc2607b68, td=0xc3f3ae10, opts=0,
file=0x0, line=0)
at /usr/home/build/src/sys/kern/kern_mutex.c:456
#24 0xc055c510 in _mtx_lock_flags (m=0xc2607b68, opts=0,
file=0xc075e7ff "/usr/home/build/src/sys/net/bpf.c", line=1119)
at /usr/home/build/src/sys/kern/kern_mutex.c:273
#25 0xc05dda38 in filt_bpfread (kn=0xc204d3fc, hint=0) at
/usr/home/build/src/sys/net/bpf.c:1119
#26 0xc0545518 in kqueue_register (kq=0xc25ff580, kev=0xd8a60c38,
td=0xc3f3ae10, waitok=1)
at /usr/home/build/src/sys/kern/kern_event.c:852
#27 0xc0544b4e in kevent (td=0xc3f3ae10, uap=0xd8a60d14) at
/usr/home/build/src/sys/kern/kern_event.c:563
#28 0xc070fa10 in syscall (frame {tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134588416, tf_esi 134586368, tf_ebp = -1077941928, tf_isp = -660206220,
tf_ebx 134570112, tf_edx = -1077941952, tf_ecx = -1077941888, tf_eax = 363,
tf_trapno = 12, tf_err = 2, tf_eip = 672189135, tf_cs = 31, tf_eflags 642,
tf_esp = -1077941988, tf_ss = 47})
at /usr/home/build/src/sys/i386/i386/trap.c:1001
#29 0xc06fa81f in Xint0x80_syscall () at
/usr/home/build/src/sys/i386/i386/exception.s:201
#30 0x0000002f in ?? ()
#31 0x0000002f in ?? ()
#32 0x0000002f in ?? ()
#33 0x0805a800 in ?? ()
#34 0x0805a000 in ?? ()
#35 0xbfbfe958 in ?? ()
#36 0xd8a60d74 in ?? ()
#37 0x08056080 in ?? ()
#38 0xbfbfe940 in ?? ()
#39 0xbfbfe980 in ?? ()
#40 0x0000016b in ?? ()
#41 0x0000000c in ?? ()
#42 0x00000002 in ?? ()
#43 0x2810cacf in ?? ()
#44 0x0000001f in ?? ()
#45 0x00000282 in ?? ()
#46 0xbfbfe91c in ?? ()
#47 0x0000002f in ?? ()
#48 0x00000000 in ?? ()
#49 0x00000000 in ?? ()
#50 0x00000000 in ?? ()
#51 0x00000000 in ?? ()
#52 0x137b8000 in ?? ()
#53 0xc41bd1c4 in ?? ()
#54 0xc3f3ae10 in ?? ()
#55 0xd8a60ca0 in ?? ()
#56 0xd8a60c7c in ?? ()
#57 0xc1a59000 in ?? ()
#58 0xc0579cb0 in sched_switch (td=0x805a000, newtd=0x8056080,
flags=---Can't read userspace from dump, or kernel process---
)
at /usr/home/build/src/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
- Christian
--
Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050209/1229e919/attachment.bin
Kris Kennaway
2005-Feb-08 17:10 UTC
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
On Wed, Feb 09, 2005 at 02:08:30AM +0100, Christian Brueffer wrote:> I'm getting this reproducible panic with a 5-STABLE system based on > sources from yesterday. The machine in question is an i386 SMP box. > > The panic is reproducible by running an updated version of the > security/scanssh port which is based on libevent. > > A crashdump is available for further investigation.Is the kernel compiled with -O2? This confuses the gdb stack trace unwinder, so you should try instead with -O. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050208/41c59c5d/attachment.bin
Christian Brueffer
2005-Feb-09 08:31 UTC
panic: _mtx_lock_sleep: recursed on non-recursive mutex bpf2 @ /usr/home/build/src/sys/net/bpf.c:1119
On Wed, Feb 09, 2005 at 02:08:30AM +0100, Christian Brueffer wrote:> I'm getting this reproducible panic with a 5-STABLE system based on > sources from yesterday. The machine in question is an i386 SMP box. > > The panic is reproducible by running an updated version of the > security/scanssh port which is based on libevent. >To aid debugging this, I have uploaded the updated version of the scanssh port: http://people.freebsd.org/~brueffer/scanssh.tar.bz2 Installing and running this port is enough to panic my SMP machine (UP works fine). - Christian -- Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050209/68ac8156/attachment.bin