Christopher SEKIYA wrote:

> I think I've isolated the commit that broke it:
> 	
> 	Module Name:    src
> 	Committed By:   simonb
> 	Date:           Tue Mar 23 02:21:49 UTC 2004
> 
> 	Modified Files:
> 	        src/lib/libc/arch/mips/gen: __setjmp14.S
> 	Added Files:
> 	        src/lib/libc/arch/mips/gen: __longjmp14.c
> 
> 	Log Message:
> 	Use setcontext() instead of sigreturn() to implement longjmp().
> 
> 	cvs rdiff -r0 -r1.1 src/lib/libc/arch/mips/gen/__longjmp14.c
> 	cvs rdiff -r1.9 -r1.10 src/lib/libc/arch/mips/gen/__setjmp14.S
> 
> ... at least, anything built after that commit exhibits the cache panic.

Yay for me :-(  Do any of the regression tests regress/lib/libc/*setjmp*
able to reproduce the panic, and if so is it easy to backtrack the kernel
to find out when that end of the problem first started occurring?

I've just tried a fresh 2.0 branch build on a little-endian "sbmips"
board, and this is what I see:

	NetBSD 2.0_BETA (GENERIC) #0: Tue May 11 12:49:29 EST 2004

	Welcome to NetBSD!

	pid 280 (csh), uid 0: exited on signal 11 (core dumped)
	Badly placed ()'s.
	rhone# 

but Manuel's "ll" test just wedges this box, such that I can't even get
in to ddb:

	rhone# alias ll ls -lgF
	rhone# ll /lib/libc.so*
	[ hang ]

I agree what userland being able to hang the kernel is definitely not
a good thing, but I can't recall what could have changed in -current
to fix the problem.  I'll look in to this further...

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/