>
>> 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.
>

I'll 'fess up to adding this 'spew'. Sorry- *I* find it useful- but
I'm happy to have it under DEBUG.

So shoot me, awready......