>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
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD 1.4.2
>Organization:
	RUNIT AS
>Environment:
	
System: SPARCsystem 600MP Series (2 X CY605C)
	Trying to boot NetBSD 1.4.2

>Description:
	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: 
13c00 
>How-To-Repeat:
	See above.

>Fix:
	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.
>Release-Note:
>Audit-Trail:
>Unformatted:
 >> NetBSD/sparc Secondary Boot, Revision 1.8
 >> (toddpw@threepio.toddpw.net, Fri Mar  3 17:51:31 PST 2000)
 boot: client IP address: 129.241.249.77
 boot: client name: anker.runit.no
 root addr=129.241.249.70 path=/var/tmp
 Booting netbsd @ 0x4000
 1056768+1738008+146404+[62268+71473]=0x2f2b71
 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
 m_access_fault4m+0x308
 memfault_sun4m(0x0, 0x0, 0xf02cfa74, 0x7a51, 0xf02cf800, 0xffffffff) at memfaul
 t_sun4m+0xe4
 _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
 c1+0xf4
 _kmeminit(0xf06ac000, 0xfe000000, 0xf02c9fe0, 0x1, 0xf06ab874, 0xf02c9fa8) at _
 kmeminit+0x10
 _uvm_init(0xf0110400, 0x1, 0xf0002000, 0xf010df20, 0xf010df18, 0x8) at _uvm_ini
 t+0x68
 _main(0x0, 0xf02c8e70, 0xf00021b8, 0xf010e0a3, 0xffef201c, 0x0) at _main+0x34
 startmap_done(0x1, 0x30c800, 0x301ee0, 0x0, 0x0, 0x8) at startmap_done+0x1cc
 db>
 
 	If my ability to disassemble "-g"-compiled .o files is up to
 	par, it would seem that this is happening near the end of
 	uvm_map():
 
 (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
 (gdb) 
 0xc10 <uvm_map+1144>:   call  0xc10 <uvm_map+1144>
 (gdb) 
 0xc14 <uvm_map+1148>:   clr  %o2
 (gdb) 
 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;
 687     
 688             UVMHIST_LOG(maphist,"<- done!", 0, 0, 0, 0);
 689             vm_map_unlock(map);
 690             return(KERN_SUCCESS);
 691     }
 692     
 693     /*
 (gdb) 
 
 	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...