From: ebiederm@xmission.com (Eric W. Biederman)
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Don Zickus <dzickus@redhat.com>,
"x86\@kernel.org" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kexec-list <kexec@lists.infradead.org>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] x86, kdump: No need to disable ioapic in crash path
Date: Wed, 02 May 2012 12:39:06 -0700 [thread overview]
Message-ID: <87vckemkyt.fsf@xmission.com> (raw)
In-Reply-To: <5C4C569E8A4B9B42A84A977CF070A35B2E4D461583@USINDEVS01.corp.hds.com> (Seiji Aguchi's message of "Wed, 2 May 2012 15:10:34 -0400")
Seiji Aguchi <seiji.aguchi@hds.com> writes:
>> Perhaps calling setup_IO_APIC before setup_local_APIC would be a better fix?
>
> I checked Intel develper's manual and there is no restriction about the order of enabling IO_APIC/local_APIC.
> So, it may work.
>
> But, I don't understand why we have to change the stable boot-up code.
Because the boot-up code is buggy. We need to get a better handle on
how it is buggy but apparently an interrupt coming in at the wrong
moment while booting with interrupts on the interrupt flag on the cpus
disalbed puts us in a state where we fail to boot.
We should be able to boot with apics enabled, and we almost can
emperically there are a few bugs.
The kdump path is particularly good at finding bugs.
> If kdump disables both local_apic and IO_APIC in proper way in 1st kernel, 2nd kernel works without any change.
We can not guarnatee disabling the local apics in the first kernel.
Ultimately the less we do in the first kernel the more reliable kdump is
going to be. Disabling the apics has been a long standing bug work
around.
At worst we may have been a smidge premature in using assuming the
kernel can boot with the apics enabled but it I would hope we can
track down and fix the boot up code.
Probably what we want to do is not to disable the I/O apics but
to program the I/O apics before we enable the local apic so that
we have control of the in-comming interrupts. But I haven't
looked at this in nearly enough detail to even guess what needs
to happen.
Eric
next prev parent reply other threads:[~2012-05-02 19:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 20:08 [PATCH] x86, kdump: No need to disable ioapic in crash path Don Zickus
2012-03-15 20:26 ` Don Zickus
2012-03-15 21:16 ` Seiji Aguchi
2012-03-15 21:33 ` Don Zickus
2012-03-15 21:37 ` Seiji Aguchi
2012-04-30 20:53 ` Don Zickus
2012-05-02 19:10 ` Seiji Aguchi
2012-05-02 19:39 ` Eric W. Biederman [this message]
2012-05-02 19:59 ` Don Zickus
2012-05-02 20:24 ` Eric W. Biederman
2012-03-29 16:02 ` Don Zickus
-- strict thread matches above, loose matches on Subject: below --
2012-02-02 18:12 Don Zickus
2012-02-02 23:24 ` Eric W. Biederman
2012-02-07 21:57 ` Don Zickus
2012-02-07 22:19 ` Vivek Goyal
2012-02-07 23:35 ` Eric W. Biederman
2012-02-08 20:11 ` Don Zickus
2012-02-08 22:55 ` Eric W. Biederman
2012-02-09 14:48 ` Don Zickus
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=87vckemkyt.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=dzickus@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seiji.aguchi@hds.com \
--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).