On Fri, 2015-06-12 at 21:55 +0300, Konstantin Belousov wrote:
> On Fri, Jun 12, 2015 at 11:49:01AM -0700, Maksim Yevmenkin wrote:
> > Andriy,
> > >> i have a question about obtaining minidump as result of panic() being
> > >> called from nmi handler. basically, i have a way to trigger nmi, and,
> > >> i would like to panic() system and obtain a minidump.
> > >>
> > >> i have modified isa_nmi() to appropriately inspect bits and return
> > >> non-zero return code. i have turned off machdep.kdb_on_nmi knob (set
> > >> it to zero). i have confirmed that amd64 trap() is called with correct
> > >> T_NMI type. i've also confirmed that panic() is called from amd64's
> > >> trap().
> > >>
> > >> the issue i have is that system is rebooting too early. basically, it
> > >> looks like minidump is started, but, for whatever reason, other cpus
> > >> are not completely stopped (or may be they are panic()ing again) and
> > >> system just reboots without having complete the minidump.
> > >>
> > >> the issue is not present when machdep.kdb_on_nmi is set to 1. in this
> > >> case, system drops into ddb prompt and 'call doadump' works as
> > >> expected. for various reasons i can not use ddb, and, would like to
> > >> have system save nmi triggered minidump completely unattended.
> > >>
> > >> can someone please give me a clue as to what i should be looking into
> > >> to make this work?
> > >
> > > could it be that more than one CPUs get the NMI at the same time?
> > i guess, its possible. is there an easy way to check for that?
> > > IF yes, then the current code wouldn't handle that well - each of the
> > > NMI-ed
> > > CPUs will try to stop all others with another NMI and it will wait until
> > > each of
> > > those CPUs sets an acknowledgement bit in its NMI handler. This scheme
> > > works
> > > fine if there's only one CPU that wants to become the master, but results
> > > in a
> > > deadlock otherwise.
> > that makes sense. i don't observe deadlock, but, simple reboot.
> I believe I posted patches to serialize ddb entrance or panics due to nmi.
> I do not have references handy, you could search lists.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
That was on freebsd-arch in July 2014.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"