[PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path
Neil Horman
nhorman at redhat.com
Wed Feb 6 15:12:23 EST 2008
On Wed, Feb 06, 2008 at 02:40:40PM -0500, Vivek Goyal wrote:
> 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
>
Can an APIC accept an NMI while already handling an NMI? I didn't think they
would interrupt one another, but rather, pend until such time as the previous
NMI was cleared
Neil
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman at redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
More information about the kexec
mailing list