Re: panic trying to play Civillization (with trace, etc.)
On 12-Mar-01 Dag-Erling Smorgrav wrote: > Mikhail Teterin <[EMAIL PROTECTED]> writes: >> > If you can, please reproduce the panic on a kernel compiled with the >> > INVARIANTS, INVARIANT_SUPPORT and WITNESS options. >> Well, with this options on, the machine does not crash, but the >> program segfaults on startup: > > The trace you're showing looks like it's from a shell script that > starts civctp. I need to see the trace from the civctp binary itself. > >> lock order reversal >> 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 >> 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 >> 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 > > Haven't seen this one before... If it's reproducible, could you do the > following: It's stupidness due to proctree and allproc locks being backed by lockmgr I think. I'm waiting on looking at this one until proctree and allproc are converted to sx locks. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
On 12 Mar, Dag-Erling Smorgrav wrote: = Mikhail Teterin <[EMAIL PROTECTED]> writes: = > > If you can, please reproduce the panic on a kernel compiled with the = > > INVARIANTS, INVARIANT_SUPPORT and WITNESS options. = > Well, with this options on, the machine does not crash, but the = > program segfaults on startup: = = The trace you're showing looks like it's from a shell script that = starts civctp. I need to see the trace from the civctp binary itself. No, that trace was obtained from a simple ktrace civctp There is no shell-wrapper around the binary: file /opt/bin/civctp /opt/bin/civctp: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, stripped It is just one big executable. You are welcome to download it from: http://aldan.algebra.com:8015/~mi/civctp-crash/civctp.bz2 uncompress it and try to run it (just 43Kb compressed). May be, it is because it is a _staticly_ linked Linux executable (the _dynamicly_ linked Netscape works fine). = > lock order reversal = > 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 = > 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 = > 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 = = Haven't seen this one before... If it's reproducible, could you do the = following: No... This the only machine I have at home. No serial console or cable... It is reproduceable -- happens now at boot time... -mi = 1) recompile your kernel with WITNESS_DDB = = 2) hook up a serial console and boot with '-h' in /boot.config = = 3) provoke the reversal, then get the output from 'trace', 'show = mutex' and 'show witness' at the DDB prompt = = 4) type 'continue' to exit DDB and continue running normally. = > lock order reversal = > 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 = > 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 = > 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 = = This is a known (and probably benign) bug. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
Mikhail Teterin <[EMAIL PROTECTED]> writes: > > If you can, please reproduce the panic on a kernel compiled with the > > INVARIANTS, INVARIANT_SUPPORT and WITNESS options. > Well, with this options on, the machine does not crash, but the > program segfaults on startup: The trace you're showing looks like it's from a shell script that starts civctp. I need to see the trace from the civctp binary itself. > lock order reversal >1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 >2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 >3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 Haven't seen this one before... If it's reproducible, could you do the following: 1) recompile your kernel with WITNESS_DDB 2) hook up a serial console and boot with '-h' in /boot.config 3) provoke the reversal, then get the output from 'trace', 'show mutex' and 'show witness' at the DDB prompt 4) type 'continue' to exit DDB and continue running normally. > lock order reversal >1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 >2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 >3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 This is a known (and probably benign) bug. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
> Mikhail Teterin <[EMAIL PROTECTED]> writes: > > Here is the trace with my attempts to browse through it. > > If you can, please reproduce the panic on a kernel compiled with the > INVARIANTS, INVARIANT_SUPPORT and WITNESS options. Well, with this options on, the machine does not crash, but the program segfaults on startup: [] 430 ktrace NAMI "/usr/games/civctp" 430 ktrace RET execve -1 errno 2 No such file or directory 430 ktrace CALL execve(0xbfbff730,0xbfbffc40,0xbfbffc48) 430 ktrace NAMI "/usr/local/sbin/civctp" 430 ktrace RET execve -1 errno 2 No such file or directory 430 ktrace CALL execve(0xbfbff730,0xbfbffc40,0xbfbffc48) 430 ktrace NAMI "/usr/local/bin/civctp" 430 civctp RET execve 0 430 civctp PSIG SIGSEGV SIG_DFL 430 civctp NAMI "civctp.core" The points of interest: . I had to brandelf the binary manually after I untarred the stuff from the CD Loki Games sent me. . The Linux Netscape continues to work properly . The binary crashes in the same fashion even when the /compat/linux is not available (not mounted), which leads me to believe, it is not recognized as a Linux binary . One does not need to be root to cause the crash (on the system without INVARIANTS and WITNESS) . The kernel has already complained twice since reboot: # dmesg [] lock order reversal 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
Mikhail Teterin <[EMAIL PROTECTED]> writes: > Here is the trace with my attempts to browse through it. If you can, please reproduce the panic on a kernel compiled with the INVARIANTS, INVARIANT_SUPPORT and WITNESS options. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic trying to play Civillization (with trace, etc.)
Hi! All of a sudden I can't play my game :( The new kernels all crash
just trying to start the executable...
Here is the trace with my attempts to browse through it. The bzip2-ed
kernel and vmcore, as well as the /sys subtree are available for
examination at:
http://aldan.algebra.com:8015/~mi/civctp-crash/
The panic-triggering (Linux) binary is also there (civctp). I don't
think you can play the game with it without the data-files and
libraries, so Loki games should not object :) Most probably you will be
able to get the same panic by just trying to run the executable, which
worked just fine with the Feb 22 current-kernel. I link all of the
modules into the kernel.
I can also give an account or two (the machine is on a static-IP DSL
link) to those who wish to take a closer look, but can not reproduce
this locally. Thanks!
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc01de0d0 in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#3 0xc02e8f65 in trap_fatal (frame=0xcf02adc4, eva=0)
at ../../i386/i386/trap.c:987
#4 0xc02e8c99 in trap_pfault (frame=0xcf02adc4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#5 0xc02e858f in trap (frame={tf_fs = -1069744104, tf_es = 16,
tf_ds = -821952496, tf_edi = -822364608, tf_esi = -1069645600,
tf_ebp = -821907952, tf_isp = -821907984, tf_ebx = 0,
tf_edx = -822364608, tf_ecx = 86, tf_eax = 1, tf_trapno = 12,
tf_err = 0, tf_eip = -1071804515, tf_cs = 8, tf_eflags = 65538,
tf_esp = 4, tf_ss = 1}) at ../../i386/i386/trap.c:448
#6 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=4,
file=0xc0324024 "../../kern/kern_shutdown.c", line=258)
at ../../kern/kern_mutex.c:525
#7 0xc01ddde5 in boot (howto=256) at ../../kern/kern_shutdown.c:258
#8 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#9 0xc02e8f65 in trap_fatal (frame=0xcf02aef4, eva=0)
at ../../i386/i386/trap.c:987
#10 0xc02e8c99 in trap_pfault (frame=0xcf02aef4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#11 0xc02e858f in trap (frame={tf_fs = -1051459560, tf_es = 16, tf_ds = 16,
tf_edi = -822364608, tf_esi = -1069645600, tf_ebp = -821907648,
tf_isp = -821907680, tf_ebx = 0, tf_edx = 1, tf_ecx = 598, tf_eax = 598,
tf_trapno = 12, tf_err = 0, tf_eip = -1071804515, tf_cs = 8,
tf_eflags = 65666, tf_esp = -822364608, tf_ss = -1069645600})
at ../../i386/i386/trap.c:448
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
#14 0xc02d705d in syscall_with_err_pushed ()
#15 0x8461eab in ?? ()
#16 0x83e012f in ?? ()
#17 0x83dfeeb in ?? ()
#18 0x81be0df in ?? ()
#19 0x81aa7c9 in ?? ()
#20 0x804b271 in ?? ()
#21 0x84b2f66 in ?? ()
#22 0x80480de in ?? ()
#23 0x846dc94 in ?? ()
(kgdb) up 12
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
(kgdb) p m
$1 = (struct mtx *) 0xc03e80e0
(kgdb) p *m
$2 = {mtx_lock = 3472602691, mtx_recurse = 1, mtx_saveintr = 0, mtx_flags = 2,
mtx_description = 0xc0341df9 "Giant", mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xcefbd400}, mtx_contested = {le_next = 0xc03e80e0,
le_prev = 0xcefbb7e0}, mtx_next = 0xc03dae60, mtx_prev = 0xc03e82a0,
mtx_debug = 0x0}
(kgdb) p m->mtx_blocked
$3 = {tqh_first = 0x0, tqh_last = 0xcefbd400}
(kgdb) l
520
521 mtx_lock_spin(&sched_lock);
522 if ((opts & MTX_QUIET) == 0)
523 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
524
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
526 MPASS(p->p_magic == P_MAGIC);
527 MPASS(p1->p_magic == P_MAGIC);
528
529 TAILQ_REMOVE(&m->mtx_blocked, p1, p_procq);
(kgdb) up
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
1247mtx_unlock(&Giant);
(kgdb) l
1242
1243/*
1244 * Release Giant if we had to get it
