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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox