From: Martin Wilck <martin.wilck@fujitsu-siemens.com>
To: "vgoyal@in.ibm.com" <vgoyal@in.ibm.com>
Cc: Chip Coldwell <coldwell@redhat.com>,
Haren Myneni <hbabu@us.ibm.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: PATCH/RFC: [kdump] fix APIC shutdown sequence
Date: Thu, 09 Aug 2007 19:35:06 +0200 [thread overview]
Message-ID: <46BB504A.9000100@fujitsu-siemens.com> (raw)
In-Reply-To: <20070809101128.GA14738@in.ibm.com>
Vivek Goyal wrote:
> Did you also check IRR bits on LAPIC. May be some interrupt is already
> being served and your new interrupts has been queued on LAPIC and IRR bit
> on LAPIC is set?
That's it. Whenever the IO-APIC IRR bit is set, I see the LAPIC IRR bit set, too.
I never see any ISR bits set. Very rarely I see that IRQs are IRQ_PENDING or
IRQ_INPROGRESS, but that's apparently unrelated to the problem.
Actually, I often see APIC IRR bits set, but it only seems to matter for
IRQs coming from the secondary IO-APIC.
Unfortunately, just writng APIC_EOI in this situation (when an IRR bit is set)
has no effect.
I have tried to set the IRQ_DISABLED flag for all IRQs. From my understanding,
if I re-enable IRQs, that disables the actual IRQ handlers, but the ack()
function of the IRQ chip (which, in our case, sends EOI) is called anyway.
*That appears to work*, in the kdump kernel the IRR is cleared.
I'll run an overnight test with that technique tonight.
Martin
--
Martin Wilck
PRIMERGY System Software Engineer
FSC IP ESP DE6
Fujitsu Siemens Computers GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn
Germany
Tel: ++49 5251 8 15113
Fax: ++49 5251 8 20409
Email: mailto:martin.wilck@fujitsu-siemens.com
Internet: http://www.fujitsu-siemens.com
Company Details: http://www.fujitsu-siemens.com/imprint.html
next prev parent reply other threads:[~2007-08-09 17:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-06 15:08 Martin Wilck
2007-08-07 14:29 ` Vivek Goyal
2007-08-07 17:41 ` Martin Wilck
2007-08-08 1:04 ` Eric W. Biederman
2007-08-08 9:03 ` Martin Wilck
2007-08-08 9:33 ` Vivek Goyal
2007-08-08 12:04 ` Martin Wilck
2007-08-08 15:21 ` Eric W. Biederman
2007-08-08 17:35 ` Martin Wilck
2007-08-08 17:56 ` Eric W. Biederman
2007-08-08 18:22 ` Martin Wilck
2007-08-08 18:38 ` Martin Wilck
2007-08-08 10:36 ` Vivek Goyal
2007-08-08 14:06 ` Chip Coldwell
2007-08-08 14:42 ` Vivek Goyal
2007-08-08 18:15 ` Martin Wilck
2007-08-09 10:11 ` Vivek Goyal
2007-08-09 17:35 ` Martin Wilck [this message]
2007-08-07 19:44 ` Chip Coldwell
2007-08-08 0:29 ` Andrew Morton
2007-08-08 8:32 ` Martin Wilck
2007-08-08 11:38 ` Vivek Goyal
2007-08-08 18:07 ` Martin Wilck
2007-08-08 21:25 ` Eric W. Biederman
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=46BB504A.9000100@fujitsu-siemens.com \
--to=martin.wilck@fujitsu-siemens.com \
--cc=coldwell@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hbabu@us.ibm.com \
--cc=kexec@lists.infradead.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
Powered by JetHome