Subject: port-sparc/10059: synetbsd-INSTALL.gz fails with "panic: kernel fault"
To: None <>
From: Havard Eidnes <>
List: netbsd-bugs
Date: 05/06/2000 16:25:09
>Number:         10059
>Category:       port-sparc
>Synopsis:       synetbsd-INSTALL.gz fails with "panic: kernel fault"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 06 16:26:00 PDT 2000
>Originator:     Havard Eidnes
>Release:        NetBSD 1.4.2
System: SPARCsystem 600MP Series (2 X CY605C)
	Trying to boot NetBSD 1.4.2

	Tried to boot this system using the network and the boot
	blocks from 1.4.2 resulted in the following panic/traceback:

<#0> ok boot net
Resetting ... 
SPARCsystem 600MP Series (2 X CY605C), No Keyboard
ROM Rev. 2.5, 128 MB memory installed, Serial #4196356.
Ethernet address 8:0:20:e:f7:94, Host ID: 71400804.

Rebooting with command: net                                           
Boot device: /iommu/sbus/lebuffer@f,40000/le@f,60000   File and args: 
	See above.

	Sorry; fixing at this level is beyond me...
	I'll however gladly test any modifications.

	For the record: booting the normal 1.4.2 GENERIC_SCSI3 kernel
	using the same setup as was used above works.
 >> NetBSD/sparc Secondary Boot, Revision 1.8
 >> (, Fri Mar  3 17:51:31 PST 2000)
 boot: client IP address:
 boot: client name:
 root addr= path=/var/tmp
 Booting netbsd @ 0x4000
 OBP version 3, revision 2.5 (plugin rev 2)
 [ preserving 133748 bytes of netbsd a.out symbol table ]
 console is ttya
 Copyright (c) 1996, 1997, 1998, 1999, 2000
     The NetBSD Foundation, Inc.  All rights reserved.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.
 data fault: pc=0xf00b8f9c addr=0x0 sfsr=1a6<PERR=0,LVL=1,AT=5,FT=1,FAV,OW>
 panic: kernel fault
 Stopped in  at  _Debugger+0x4:  jmpl            [%o7 + 0x8], %g0
 db> trace
 _mem_access_fault4m(0x0, 0x1a6, 0x0, 0xf010dcd0, 0xf0396874, 0xf0002000) at _me
 memfault_sun4m(0x0, 0x0, 0xf02cfa74, 0x7a51, 0xf02cf800, 0xffffffff) at memfaul
 _uvm_map(0xf051e000, 0x6ac000, 0x0, 0x0, 0x0, 0x0) at _uvm_map+0x478
 _uvm_km_alloc1(0xf02aeed8, 0x6ac000, 0x1, 0x0, 0x0, 0xf00f44e8) at _uvm_km_allo
 _kmeminit(0xf06ac000, 0xfe000000, 0xf02c9fe0, 0x1, 0xf06ab874, 0xf02c9fa8) at _
 _uvm_init(0xf0110400, 0x1, 0xf0002000, 0xf010df20, 0xf010df18, 0x8) at _uvm_ini
 _main(0x0, 0xf02c8e70, 0xf00021b8, 0xf010e0a3, 0xffef201c, 0x0) at _main+0x34
 startmap_done(0x1, 0x30c800, 0x301ee0, 0x0, 0x0, 0x8) at startmap_done+0x1cc
 	If my ability to disassemble "-g"-compiled .o files is up to
 	par, it would seem that this is happening near the end of
 (gdb) i li 689
 Line 689 of "../../../../uvm/uvm_map.c" starts at address 0xc08 <uvm_map+1136>
    and ends at 0xc18 <uvm_map+1152>.
 (gdb) x/i 0xc08
 0xc08 <uvm_map+1136>:   mov  %l3, %o0
 (gdb) x/i
 0xc0c <uvm_map+1140>:   mov  6, %o1
 0xc10 <uvm_map+1144>:   call  0xc10 <uvm_map+1144>
 0xc14 <uvm_map+1148>:   clr  %o2
 0xc18 <uvm_map+1152>:   clr  %i0
 (gdb) l 689
 684             if ((map->first_free == prev_entry) &&
 685                 (prev_entry->end >= new_entry->start))
 686                     map->first_free = new_entry;
 688             UVMHIST_LOG(maphist,"<- done!", 0, 0, 0, 0);
 689             vm_map_unlock(map);
 690             return(KERN_SUCCESS);
 691     }
 693     /*
 	and 1144 == 0x478 (see traceback above)
 	/sys/vm/vm_map.h defines vm_map_unlock as:
 #define vm_map_unlock(map) \
                 lockmgr(&(map)->lock, LK_RELEASE, (void *)0)
 	It *does* however sound a little nuts that it should fault on
 	a call instruction, and the preceding ones also look
 	"innocent" enough to me...