Re: obtaining a minidump from panic() called from NMI handler

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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
>