From owner-freebsd-sparc64@FreeBSD.ORG Fri Dec 17 20:22:17 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C561616A4CE for ; Fri, 17 Dec 2004 20:22:17 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB6943D49 for ; Fri, 17 Dec 2004 20:22:17 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14857 invoked from network); 17 Dec 2004 20:22:17 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 17 Dec 2004 20:22:15 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBHKLhg4020130; Fri, 17 Dec 2004 15:22:12 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-sparc64@FreeBSD.org Date: Fri, 17 Dec 2004 15:22:09 -0500 User-Agent: KMail/1.6.2 References: <200409031451.03623.jhb@FreeBSD.org> In-Reply-To: <200409031451.03623.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412171522.09523.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: alc@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Re: sparc64 kernels have KVM problems(?) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 20:22:18 -0000 On Friday 03 September 2004 02:51 pm, John Baldwin wrote: > I finally got a place to setup my ultra60 and turned it on the first time > in about a year and a half last week. I'm currently in the process of > updating it and have hit something of a bump (though I'll work around it > for now). It seems that while a GENERIC kernel works fine, my custom > kernel config that just removes unused devices from GENERIC doesn't boot. > Instead it ends up doing a panic very early on like so: > > OK boot test -s > /boot/test/kernel data=0x2bfe08+0x54fa8 syms=[0x8+0x4a880+0x8+0x3f4b1] > Turning off DMA for ATA. > jumping to kernel entry at 0xc0040000. > GDBstray vector interrupt 2029 > > : no debug ports present > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-CURRENT #45: Fri Sep 3 10:47:55 EDT 2004 > john@foo.baldwin.cx:/usr/src/sys/sparc64/compile/FOO > panic: trap_pfault: vmspace NULL > cpuid = 0 > KDB: enter: panic > [thread 0] > Stopped at 0xc01175d8: ta %xcc, 1 > db> tr > (null)() at 0xc00fa59c > (null)() at 0xc024c068 > (null)() at 0xc024c3d8 > (null)() at 0xc0040ff8 > (null)() at 0xc02480f8 > (null)() at 0xc02488a4 > (null)() at 0xc021baf4 > (null)() at 0xc022f578 > (null)() at 0xc00effc0 > (null)() at 0xc00f2848 > (null)() at 0xc00f2930 > (null)() at 0xc00d2b98 > (null)() at 0xc0040034 > db> reset > > The traceback corresponds to this (note that gdb gets the trap_pfault() > frame wrong by a few lines which is odd): > > 0xc00fa59c is in panic (../../../kern/kern_shutdown.c:536). > 0xc024c068 is in trap_pfault (../../../sparc64/sparc64/trap.c:456). > 0xc024c3d8 is in trap (../../../sparc64/sparc64/trap.c:324). > No source file for address 0xc0040ff8. > 0xc02480f8 is in pmap_remove_tte (../../../sparc64/sparc64/pmap.c:1121). > 0xc02488a4 is in pmap_enter (../../../sparc64/sparc64/pmap.c:1365). > 0xc021baf4 is in kmem_malloc (../../../vm/vm_kern.c:404). > 0xc022f578 is in uma_large_malloc (../../../vm/uma_core.c:2592). > 0xc00effc0 is in malloc (../../../kern/kern_malloc.c:292). > 0xc00f2848 is in mtx_pool_create (../../../kern/kern_mtxpool.c:129). > 0xc00f2930 is in mtx_pool_setup_dynamic (../../../kern/kern_mtxpool.c:160). > 0xc00d2b98 is in mi_startup (../../../kern/init_main.c:211). > 0xc0040034 is at ../../../sparc64/sparc64/locore.S:86. > > Anyone have any ideas? (Note that this is with a 32-bit time_t still, I'm > still in the process of doing the 64BTT update and was trying to figure > this out before going on.) I finally figured this out. Removing WITNESS from my kernel causes this panic somehow. Putting WITNESS back in clears up the panic. Any ideas? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org