>Number:         6132
>Category:       port-arm32
>Synopsis:       shark kernels die with "stack limit exceeded"
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep  9 12:50:01 1998
>Last-Modified:
>Originator:     Jason R Thorpe
>Organization:
Numerical Aerospace Simulation Facility - NASA Ames
>Release:        NetBSD 1.3H, Wed Sep  9 12:01:45 PDT 1998
>Environment:
	
System: NetBSD lestat 1.3F NetBSD 1.3F (LESTAT) #138: Wed Jul 1 22:08:59 PDT 1998 thorpej@lestat:/tmp_mnt/dracul/u5/netbsd/src/sys/arch/sparc/compile/LESTAT sparc


>Description:
	Recent Shark kernels (since CATS support code went in) die
	with the following, after proceeding some ways through the
	multi-user boot process.

[ 10 finger copy ]

starting nfs daemons: nfsiod amdStack limit exceeded 32173 200
Stack limit exceeded 32173 200
 Data abort: 'Translation fault (section)' status=005 address=bda8bc68 PC=f00e18c4
Section fault in SVC mode
[u]vm_fault(0xf011, bda8b000, 3, 0) -> 5
panic: Halting (frame = 0xf03ddc6c)

Backtrace looks like:

_Debugger
_panic
_data_abort_handler
_selwakeup
_logwakeup
_printf
_data_abort_handler
_mi_switch
_tsleep
_uvm_scheduler
_main

	I don't believe this is related to the process reaper, as
	my test kernels on the Shark worked fine before I committed
	that code, and the boot process makes it through several
	exit cycles before it dies.  Note that it does not always
	die after amd... another attempt died after ypbind started.

>How-To-Repeat:
	Built a Shark kernel, boot it on a Shark.  Watch it lose.

>Fix:
	Unknown.
>Audit-Trail:
>Unformatted: