Re: CVS commit: src/sys/kern

[Darren Reed <darrenr%NetBSD.org@localhost>]

On Sat, Jan 28, 2006 at 01:06:37PM +0100, Manuel Bouyer wrote:
> On Sat, Jan 28, 2006 at 11:51:19AM +0000, Darren Reed wrote:
> > For me, I'm not comfortable it will be of value as it presupposes that
> > the ddb parser is working and that the kernel will survive until that
> > time.
> 
> If the system is in such a state that ddb can't print its prompt,
> it's not clear if db_stack_trace_print() will work better. Also, on some
> platforms, ddb() may need some more initialisations before
> db_stack_trace_print() will work (it's just theory, I've no example of
> platforms where this would be the case).
> Also, with your change there's no way to get the old ddb.onpanic=0
> behavior: if ddb.onpanic is not 1, db_stack_trace_print will always be
> called.

Huh ?

ddb.onpanic=0 functionality has not changed.  For non-zero values
that are neither 1 or 2, it has changed, but they're undefined.

It previously did "if (db_onpanic)" and I made it "if (db_onpanic == 1)"

The other "changes" were style...

Or am I missing something ?

> > and nearly every time there is a panic,
> > the system faults again in ddb, either locking ddb and the system up
> > or just preventing you from getting what you need.
> 
> The system is seriously messed up then. Maybe something has overwritten
> the page tables, or something like that. But the most common problem leading
> to a non-working ddb is when the stack pointer has jumped to nowhere, or
> the kernel is out of stack space (too much data allocated on stack, or
> recursive function call). I would recommend setting printing the register
> contents in addition to the stack trace, to see the stack pointer value
> (options DDB_COMMANDONENTER="trace;show registers")

So what does this tell you ?

>From a digital camera:
-------------------------
fatal protection fault in supervisor mode
trap type 4 code 7fb eip c0100b7f cs 8 eflags 10246 cr2 804eeac ilevel 0
panic: trap
Begin traceback...
trap() at netbsd:trap+0x149
--- trap (number 4) ---
cpu_switch(c0363ba0,0,ca342000,282,c0365a20) at netbsd:cpu_switch+0x9f
fatal protection fault in supervisor mode
trap type 4 code 7fb eip c0100b7f cs 8 eflags 10246 cr2 804eeac ilevel 0
Faulted in mid-traceback:aborting...
<system hang>

Darren