From: Andi Kleen <ak@muc.de>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
Fastboot mailing list <fastboot@lists.osdl.org>,
Morton Andrew Morton <akpm@osdl.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [RFC][PATCH] kdump: x86_64 timer interrupt lockup due to pending interrupt
Date: 6 Mar 2006 22:43:32 +0100
Date: Mon, 6 Mar 2006 22:43:32 +0100 [thread overview]
Message-ID: <20060306214332.GA18529@muc.de> (raw)
In-Reply-To: <20060306164034.GB10594@in.ibm.com>
On Mon, Mar 06, 2006 at 11:40:34AM -0500, Vivek Goyal wrote:
>
> o check_timer() routine fails while second kernel is booting after a crash
> on an opetron box. Problem happens because timer vector (0x31) seems to be
> locked.
>
> o After a system crash, it is not safe to service interrupts any more, hence
> interrupts are disabled. This leads to pending interrupts at LAPIC. LAPIC
> sends these interrupts to the CPU during early boot of second kernel. Other
> pending interrupts are discarded saying unexpected trap but timer interrupt
> is serviced and CPU does not issue an LAPIC EOI because it think this
> interrupt came from i8259 and sends ack to 8259. This leads to vector 0x31
> locking as LAPIC does not clear respective ISR and keeps on waiting for
> EOI.
>
> o In this patch, one extra EOI is being issued in check_timer() to unlock the
> vector. Please suggest if there is a better way to handle this situation.
Shouldn't we rather do this for all interrupts when the APIC is set up?
I don't see how the timer is special here.
-Andi
next prev parent reply other threads:[~2006-03-06 21:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 16:40 [RFC][PATCH] kdump: x86_64 timer interrupt lockup due to pending interrupt Vivek Goyal
2006-03-06 21:43 ` Andi Kleen [this message]
2006-03-07 22:20 ` Vivek Goyal
2006-03-07 23:43 ` Eric W. Biederman
2006-03-08 1:26 ` Vivek Goyal
2006-03-08 4:04 ` Eric W. Biederman
2006-03-08 5:31 ` 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=20060306214332.GA18529@muc.de \
--to=ak@muc.de \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.