Date: Fri, 12 Jun 2015 20:38:13 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com>, "current@freebsd.org" <current@FreeBSD.org> Subject: Re: obtaining a minidump from panic() called from NMI handler Message-ID: <557B1905.80307@FreeBSD.org> In-Reply-To: <CAFPOs6qsFZKMVzLEDL5X77H6s5LoTjsc4SkMWgR0D_P8RQG4YQ@mail.gmail.com> References: <CAFPOs6qsFZKMVzLEDL5X77H6s5LoTjsc4SkMWgR0D_P8RQG4YQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/06/2015 20:36, Maksim Yevmenkin wrote: > hello, > > 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? Maksim, could it be that more than one CPUs get the NMI at the same time? 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557B1905.80307>