On Wed, 10 Jun 1998 16:45:45 -0700 (MST) 
 Tim Rightnour <root@garbled.net> wrote:

 > fatal user trap:
 > 
 >     trap entry = 0x2 (memory management fault)
 >     a0         = 0xffffffffc8000004
 >     a1         = 0x1
 >     a2         = 0x1
 >     pc         = 0x1200205b0
 >     ra         = 0x12001a8d4
 >     curproc    = 0xfffffe0000229c00
 >         pid = 22188, comm = make
 > 
 > Is this just a really long way of saying "SIGBUS" ?  I got 2 of these (from the
 > same make pid) while compiling current this afternoon.

No... if it had been an error in user space, it would have been SIGSEGV.  But
the address (a0) is in kernel space.

Let's take a look at what we have here:

	a0 == 0xffffffffc8000004.  That is in K1SEG, i.e. a mapped kernel
	segment.

	a1 == 1.  That means "access violation".  The address is mapped
	and valid, but the user is not allowed to access it.  (Makes sense;
	it's a kernel address :-)

	a2 == 1.  That means "during a store".

So, the user attempted to write to 0xffffffffc8000004, and it generated
a trap.  Why it generated a _FATAL_ trap, I don't know.  Why make(1)
attempted to access that kernel virtual address, I don't know.

How easily can you reproduce this?  What NetBSD version are you running?

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 428 6939