Re: Boot fail as kvm guest

[David Young <dyoung%pobox.com@localhost>]

On Fri, Feb 17, 2012 at 03:00:09PM +0100, Marc Balmer wrote:
> Am 17.02.12 14:41, schrieb Manuel Bouyer:
> > On Fri, Feb 17, 2012 at 02:12:35PM +0100, Marc Balmer wrote:
> >> Am 17.02.12 14:06, schrieb Hubert Feyrer:
> >>> On Fri, 17 Feb 2012, Kevin Bowling wrote:
> >>>> fatal protection fault in supervisor mode
> >>>> trap type 4 code 0 rip ffffffff80259023 cs 8 rflags 10246 cr2 0 cpl 8
> >>>> rsp fffff
> >>>> fff81032c18
> >>>> kernel: protection fault trap, code=0
> >>>> Stopped in pid 0.1 (system) at netbsd:rdmsr_locked+0xb: rdmsr
> >>>
> >>> I think NetBSD should add a stack trace on panics automatically...
> >>
> >> Can't that be achieved using ddb.commandonenter ?
> >>
> >> Or should a ddb.stacktrace sysctl variable be introduced for this?
> > 
> > No ddb.stacktrace please, ddb.commandonenter is fine for this.
> > Maybe we should eventually create a bt_allcpu (the name can be discussed :)
> > to get stack traces of all CPUs with a single command ?
> 
> on a side note, ddb.commandonenter can be quite nasty,

It sure can!

Oftentimes on i386 of mine where I set ddb.commandonenter to 'bt; show
reg', I find an uninterruptible ddb/panic loop: panic -> bt; show reg
-> re-panic -> bt; show reg -> ....

Maybe s/loop/recursion/ in the above.

Somewhere I have a patch that fixes some (but not all) loops.  I wasn't
very satisfied with my patch because (1) it wasn't 100% effective and
(2) I felt that it just added to existing half-measures.

I don't think that we should automatically print a backtrace until we
have a handle on some of the ddb bugs.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981