From owner-freebsd-current Mon Mar 12 14:29: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 44D4337B718 for ; Mon, 12 Mar 2001 14:28:56 -0800 (PST) (envelope-from mi@misha.privatelabs.com) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id RAA12406; Mon, 12 Mar 2001 17:49:12 -0500 Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.1/8.11.1) with ESMTP id f2CMSoC10222; Mon, 12 Mar 2001 17:28:52 -0500 (EST) (envelope-from mi@misha.privatelabs.com) Message-Id: <200103122228.f2CMSoC10222@misha.privatelabs.com> Date: Mon, 12 Mar 2001 17:28:49 -0500 (EST) From: mi@aldan.algebra.com Subject: Re: panic trying to play Civillization (with trace, etc.) To: Dag-Erling Smorgrav Cc: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12 Mar, Dag-Erling Smorgrav wrote: = Mikhail Teterin 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message