From: "Wei, Jiangang" <weijg.fnst@cn.fujitsu.com>
To: "ebiederm@xmission.com" <ebiederm@xmission.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Cao, Jin" <caoj.fnst@cn.fujitsu.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"bhe@redhat.com" <bhe@redhat.com>,
"xpang@redhat.com" <xpang@redhat.com>,
"kernel@kyup.com" <kernel@kyup.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"Izumi, Taku" <izumi.taku@jp.fujitsu.com>
Subject: Re: [PATCH v2 0/3] Fix dump-capture kernel hangs with notsc
Date: Tue, 2 Aug 2016 07:45:08 +0000 [thread overview]
Message-ID: <1470123720.2274.53.camel@localhost> (raw)
In-Reply-To: <87twf4xvpd.fsf@x220.int.ebiederm.org>
Hi Eric,
Thanks for your reply firstly.
On Mon, 2016-08-01 at 12:09 -0500, Eric W. Biederman wrote:
> "Wei, Jiangang" <weijg.fnst@cn.fujitsu.com> writes:
>
> > Ping ...
> > May I ask for some community attention to this series?
> > I purpose is fixing the dump-capture kernel hangs in
> > calibrate_delay_converge() while specifying notsc.
>
> Did you not see my reply to patch 3/3?
Yes, I read your email and made a reply
(https://lkml.org/lkml/2016/7/26/112) . I put forward several questions
in that letter, but no feedback...
>
> The short version of my feedback is that you seem to be fixing a case
> that should not exist. So the good fix is to skip completely past
> virtual wire mode and into full apic mode as soon as possible.
I am afraid that there are some disagreements between us.
1) The case that dump-capture kernel boot up with the disabled APIC is
very real, and the bug can be reproduced 100%. I want to emphasize that
there is no guarantee of the interrupt mode of APIC and status of local
APIC, Especially for the dump-capture kernel that won't through the BIOS
phrase. That's why I do more check in init_bsp_APIC(), not only depends
on the MP tables which be generated before the first kernel boots up.
Make a point here, The BIOS must disable interrupts to all processors
and set the APICs to the system initial state before giving control to
the operating system. That means APICs won't be reset to initial state
without BIOS phrase.
2) Your proposal (switch into full apic mode as soon as possible) seems
to contradict the Intel Spec, "An MP operating system is booted under
either one of the two PC/AT-compatible modes. Later the operating system
switches to Symmetric I/O Mode **as it enters multiprocessor mode**."
And in other words, the BSP should be in PIC mode or Virtual wire mode
in startup stage.
3) The apic initialization codes maybe need a overhaul, but it goes out
the scope of this patch. I focus on fixing kdump failure with notsc. And
the apic initialization codes has no modification for a long time and
can be regard as stable. Overhaul of it increases the chances of
hitting a bug.
If there's anything wrong with my understanding, please point out.
Thanks,
wei
>
> For a subset of cases the code already supports that.
>
> Eric
>
>
next prev parent reply other threads:[~2016-08-02 7:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 2:59 [PATCH v2 0/3] Fix dump-capture kernel hangs with notsc Wei Jiangang
2016-07-26 2:59 ` [PATCH v2 1/3] x86/apic: Remove "focus disabled" for 64bit case Wei Jiangang
2016-07-26 2:59 ` [PATCH v2 2/3] x86/apic: Update comment about disabling processor focus Wei Jiangang
2016-07-26 2:59 ` [PATCH v2 3/3] x86/apic: Improved the setting of interrupt mode for bsp Wei Jiangang
2016-07-26 3:53 ` Eric W. Biederman
2016-07-26 8:05 ` Wei, Jiangang
2016-08-02 14:26 ` Eric W. Biederman
2016-08-04 10:17 ` Wei, Jiangang
2016-08-04 13:52 ` Eric W. Biederman
2016-08-01 6:44 ` [PATCH v2 0/3] Fix dump-capture kernel hangs with notsc Wei, Jiangang
2016-08-01 17:09 ` Eric W. Biederman
2016-08-02 7:45 ` Wei, Jiangang [this message]
2016-08-02 14:21 ` bhe
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=1470123720.2274.53.camel@localhost \
--to=weijg.fnst@cn.fujitsu.com \
--cc=bhe@redhat.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=kernel@kyup.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xpang@redhat.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