From: Vivek Goyal <vgoyal@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, kexec@lists.infradead.org
Subject: Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path
Date: Wed, 6 Feb 2008 14:40:40 -0500 [thread overview]
Message-ID: <20080206194040.GA11886@redhat.com> (raw)
In-Reply-To: <20080206192555.GA24910@hmsendeavour.rdu.redhat.com>
On Wed, Feb 06, 2008 at 02:25:55PM -0500, Neil Horman wrote:
> Hey all-
> A hang on kdump was reported to me awhile back, only when systems died
> via nmi watchdog panic. The hang wouldn't always be in the same place, but it
> would usually be somewhere down in purgatory. In looking at the code, it
> occured to me that since, during an nmi interrupt, we won't be able to handle
> additional interrupts, that we won't be able to halt the other processors on a
> system like we try to do in machine_crash_shutdown. As such, it appears that
> leaving the other cpus running exposes us to the risk that another processor
> will encounter an error and halt the system while we are trying to boot the
> kdump kernel, and that can result in a hang. I wrote the attached patch to end
> the nmi interrupt prior to calling crash_kexec from within die_nmi, and testing
> here has proven successfull.
>
Hi Neil,
Why wouldn't I be able to stop other cpus if I am inside an NMI handler? I
just need to send an NMI IPI to other cpus and they should be able to
receive and handle it?
Thanks
Vivek
next prev parent reply other threads:[~2008-02-06 19:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-06 19:25 [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path Neil Horman
2008-02-06 19:40 ` Vivek Goyal [this message]
2008-02-06 20:12 ` Neil Horman
2008-02-06 20:21 ` H. Peter Anvin
2008-02-06 21:04 ` Neil Horman
2008-02-06 20:35 ` Vivek Goyal
2008-02-06 22:00 ` Ingo Molnar
2008-02-06 22:48 ` Vivek Goyal
2008-02-06 22:53 ` Ingo Molnar
2008-02-06 22:56 ` H. Peter Anvin
2008-02-06 23:36 ` Ingo Molnar
2008-02-06 23:50 ` Vivek Goyal
2008-02-07 0:31 ` Eric W. Biederman
2008-02-07 0:39 ` Ingo Molnar
2008-02-07 1:30 ` Eric W. Biederman
2008-02-07 12:17 ` Neil Horman
2008-02-07 12:24 ` Ingo Molnar
2008-02-07 20:37 ` Neil Horman
2008-02-08 16:14 ` Neil Horman
2008-02-08 16:45 ` Vivek Goyal
2008-02-08 17:26 ` Neil Horman
2008-02-12 21:08 ` Neil Horman
2008-02-15 14:02 ` Eric W. Biederman
2008-02-20 14:57 ` Neil Horman
2008-02-08 16:54 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080206194040.GA11886@redhat.com \
--to=vgoyal@redhat.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nhorman@tuxdriver.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox