From: ebiederm@xmission.com (Eric W. Biederman)
To: Don Zickus <dzickus@redhat.com>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
vgoyal@redhat.com, kexec-list <kexec@lists.infradead.org>
Subject: Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
Date: Tue, 31 Jan 2012 14:38:15 -0800 [thread overview]
Message-ID: <m1vcnr33c8.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20120131222751.GE5650@redhat.com> (Don Zickus's message of "Tue, 31 Jan 2012 17:27:51 -0500")
Don Zickus <dzickus@redhat.com> writes:
> On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
>> > The problem is that although kdump tries to shutdown minimal hardware,
>> > it still needs to disable the IO APIC. This requires spinlocks which
>> > may be held by another cpu. This other cpu is being held infinitely in
>> > an NMI context by kdump in order to serialize the crashing path. Instant
>> > deadlock.
>>
>> Can you test to see if kexec on panic still needs to disable the IO
>> APIC. Last I looked we were close if not all of the way there to not
>> needing to boot the kernel in pic mode?
>
> Ok, so you just blindly remove disable_IO_APIC from
> native_machine_crash_shutdown and re-run some panic tests on various
> machines? What about the disable_IO_APIC path in native_machine_shutdown?
>
Yes. Just native_machine_crash_shutdown.
native_machine_shutdown is the case when all is good and we attempt to
put the hardware back the way we found it.
Any normal x86 machine that the kernel runs in ioapic mode should be
enough to get a first approximation.
> Also, where could I look to see if that work was done? Is that in the
> ioapic setup code?
The primary question is do we call the ioapic setup code without calling
the pic setup code first. On some embedded x86 platforms we certainly
do. I don't know if that code has been generalized.
Historically the problem is that we started the pit timer in pic mode
and used that to calibrate the delay loop.
So what we are looking to verify is that the linux kernel boot skip
pic mode entirely.
Eric
next prev parent reply other threads:[~2012-01-31 22:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 21:25 [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq Don Zickus
2012-01-31 21:37 ` Vivek Goyal
2012-01-31 22:08 ` Eric W. Biederman
2012-01-31 22:27 ` Don Zickus
2012-01-31 22:38 ` Eric W. Biederman [this message]
2012-02-01 23:04 ` Don Zickus
2012-02-02 1:34 ` Eric W. Biederman
2012-02-02 15:33 ` Don Zickus
2012-02-02 17:45 ` Don Zickus
2012-02-20 15:20 ` Seiji Aguchi
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=m1vcnr33c8.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=dzickus@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).