From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 14:54:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2580616A4CF; Thu, 8 Jul 2004 14:54:10 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF5B543D55; Thu, 8 Jul 2004 14:54:09 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i68Es8qM004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 10:54:08 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i68Es3GB020597; Thu, 8 Jul 2004 10:54:03 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16621.24587.229940.823746@grasshopper.cs.duke.edu> Date: Thu, 8 Jul 2004 10:54:03 -0400 (EDT) To: Ken Smith In-Reply-To: <20040708135441.GD15096@electra.cse.Buffalo.EDU> References: <20040708135441.GD15096@electra.cse.Buffalo.EDU> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Alpha problems (though maybe not just Alpha...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2004 14:54:10 -0000 Ken Smith writes: > > FYI, the Alpha reference machine in the cluster has had problems the > past few days when anything significant (e.g. 'make buildworld'...) > gets run on it. It usually locks up solid right after printing > this on the console: > > panic() at panic+0x200 > _mtx_assert() at _mtx_assert+0xb4 > vrele() at vr 16 32 48 64 80 A mutex assert failed in vrele(). The first one that comes to mind is the GIANT_REQUIRED; right at the top. Its really too bad that we don't have the rest of the stack. The remainder of the output is quite strange.. It almost looks like it has stopped printing the stack trace and started taking a dump, and then panic'ed taking the dump (ahc intr might support that): > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > cpuid = 0 > faulting va = 0x0 > type = access violation > cause = instruction fetch > pc = 0x0 > ra = 0x0 > sp = 0xfffffe00317bfc70 > curthread = 0xfffffc007d772000 > pid = 23, comm = intr: ahc1 > > spin lock sched lock held by 0xfffffc007d772000 for > 5 seconds A va and ra of 0 means that it followed a null function pointer, or the stack got corrupted and it tried to return to the wrong place... Can you try disabling dumps, and disabling kern.sync_on_panic and see if you can get a decent stack trace? Thanks, Drew