[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Boot fail as kvm guest
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.
dyoung%pobox.com@localhost Urbana, IL (217) 721-9981
Main Index |
Thread Index |