sparc64 kernels have KVM problems(?)

John Baldwin jhb at
Fri Dec 17 12:22:18 PST 2004

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 at
> 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 <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-sparc64 mailing list