> fatal user trap:
> 
>     trap entry = 0x2 (memory management fault)
>     a0         = 0x0
>     a1         = 0x1
>     a2         = 0xffffffffffffffff
>     pc         = 0x0
>     ra         = 0x0
>     curproc    = 0xfffffe004a647000
>         pid = 3692, comm = getty

are you wondering about the trap itself, or the spew?

Unfortunately, the information present is just about useless for
debugging the trap, except that it looks like it's dereferenceing
NULL, perhaps by jumping to zero.  I suggest you rlogin to the machine
and attach to the process with gdb.  (it won't dump core since it's
setuid.)

As for the spew, i'm going to remove that in most situations.  kernels
_should not_ spew random crap to the console if a program happens to
crash.  (*chuckle*  it actually opens the door wider for an obscure
denial of service attack.)  I'll leave it in #ifdef DEBUG, but will be
removing DEBUG from the GENERIC kernel.


cgd