From owner-freebsd-current@FreeBSD.ORG Sat Jun 13 13:17:30 2015 Return-Path: Delivered-To: current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E17397C6; Sat, 13 Jun 2015 13:17:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBDFE71; Sat, 13 Jun 2015 13:17:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5DDHPx9079654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 13 Jun 2015 06:17:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557C2D5F.4080005@freebsd.org> Date: Sat, 13 Jun 2015 21:17:19 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Maksim Yevmenkin , Andriy Gapon CC: "current@freebsd.org" Subject: Re: obtaining a minidump from panic() called from NMI handler References: <557B1905.80307@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 13:17:31 -0000 On 6/13/15 2:49 AM, 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? hard code checks in the code so that all except the first do something different. (even only as a debug check).. like write to some location and loop... > >> 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >