panic: mutex sleepq chain not owned

From: Milos Vyletel <mv_at_rulez.sk>
Date: Tue, 9 Oct 2007 20:47:41 +0200
Hi,

after csuping today current (maybe even before, because my system hang with
Xorg runnig quite often, but i thought because it was because buggy Xorg),
i've seen this panic while working on console. Here are some info.

FreeBSD 7.0-CURRENT amd64

CPU: Intel(R) Core(TM)2 Quad CPU    Q6600  _at_ 2.40GHz (2402.42-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 4
usable memory = 4284162048 (4085 MB)
avail memory  = 4128329728 (3937 MB)

panic: mutex sleepq chain not owned at /usr/src/sys/kern/subr_sleepqueue.c:619
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x16d
unlock_spin() at unlock_spin
sleepq_resume_thread() at sleepq_resume_thread+0xa3
sleepq_broadcast() at sleepq_broadcast+0x81
txg_sync_thread() at txg_sync_thread+0x11e
fork_exit() at fork_exit+0x128
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffffbe82d30, rbp = 0 ---
KDB: enter: panic
Physical memory: 4085 MB
Dumping 1320 MB: 1305 1289 1273 1257 1241 1225 1209 1193 1177 1161 1145 1129
1113 1097 1081 1065 1049 1033 1017 1001 985 969 953 937 921 905 889 873 857 841
825 809 793 777 761 745 729 713 697 681 665 649 633 617 601 585 569 553 537 521
505 489 473 457 441 425 409 393 377 361 345 329 313 297 281 265 249 233 217 201
185 169 153 137 121 105 89 73 57 41 25 9

#0  doadump () at pcpu.h:194
194     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:194
#1  0xffffffff80179afc in db_fncall (dummy1=Variable "dummy1" is not available.
	) at /usr/src/sys/ddb/db_command.c:486
#2  0xffffffff80179ff0 in db_command_loop () at
	/usr/src/sys/ddb/db_command.c:401
#3  0xffffffff8017b90d in db_trap (type=Variable "type" is not available.
	) at /usr/src/sys/ddb/db_main.c:222
#4  0xffffffff8024e33a in kdb_trap (type=3, code=0, tf=0xfffffffffbe82930) at
	/usr/src/sys/kern/subr_kdb.c:502
#5  0xffffffff8035e3d3 in trap (frame=0xfffffffffbe82930) at
	/usr/src/sys/amd64/amd64/trap.c:472
#6  0xffffffff803451ae in calltrap () at
	/usr/src/sys/amd64/amd64/exception.S:169
#7  0xffffffff8024e4e3 in kdb_enter (msg=0xffffffff80a20fe0 "") at cpufunc.h:63
#8  0xffffffff8022916a in panic (fmt=Variable "fmt" is not available.
	) at /usr/src/sys/kern/kern_shutdown.c:547
#9  0xffffffff8021e91d in _mtx_assert (m=Variable "m" is not available.
	) at /usr/src/sys/kern/kern_mutex.c:623
#10 0xffffffff802555a0 in sleepq_resume_thread (sq=0xffffff000364a4b0,
	td=0xffffff0004b2d9f0, pri=-1)
    at /usr/src/sys/kern/subr_sleepqueue.c:619
#11 0xffffffff80255c84 in sleepq_broadcast (wchan=0xffffff0006437cd0,
    flags=Variable "flags" is not available.
    ) at /usr/src/sys/kern/subr_sleepqueue.c:755
#12 0xffffffff8063f860 in ?? ()
#13 0xffffff000623cc00 in ?? ()
#14 0xffffff0006437d70 in ?? ()
#15 0xffffff0006437cd0 in ?? ()
#16 0xffffff0006437d60 in ?? ()
#17 0xffffff0006437d90 in ?? ()
#18 0xffffff0006437dc8 in ?? ()
#19 0xffffff0006437cd0 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0xffffff00061ece00 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x000000001ffa263f in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0xffffff0006437c00 in ?? ()
#29 0xffffff0004b8f9f0 in ?? ()
#30 0xffffffff8063f742 in ?? ()
#31 0xffffff0004ba2000 in ?? ()
#32 0xfffffffffbe82c80 in ?? ()
#33 0xfffffffffbe82c70 in ?? ()
#34 0xffffffff8020e12b in fork_exit (callout=0xffffff0006437cc8, arg=0x0,
    frame=0xffffff0006437d80) at /usr/src/sys/kern/kern_fork.c:796
    Previous frame identical to this frame (corrupt stack?)

Hope this help to investigate what's wrong. I have kernel.debug and vmcore, so
let me know if there is something else what might help.

mv
Received on Tue Oct 09 2007 - 17:04:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC