Date: Fri, 12 Jun 2015 11:49:01 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: obtaining a minidump from panic() called from NMI handler Message-ID: <CAFPOs6p5yTvdbJXPOKXuagZxj%2Bu-pE3kt5fsCWCpPVj4vktO%2Bg@mail.gmail.com> In-Reply-To: <557B1905.80307@FreeBSD.org> References: <CAFPOs6qsFZKMVzLEDL5X77H6s5LoTjsc4SkMWgR0D_P8RQG4YQ@mail.gmail.com> <557B1905.80307@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6p5yTvdbJXPOKXuagZxj%2Bu-pE3kt5fsCWCpPVj4vktO%2Bg>