From: Ingo Molnar <mingo@kernel.org>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
Denys Vlasenko <dvlasenk@redhat.com>,
Oleg Nesterov <oleg@redhat.com>, Dave Hansen <dave@sr71.net>
Subject: Re: [all better] Re: regression: massive trouble with fpu rework
Date: Mon, 29 Jun 2015 08:40:08 +0200 [thread overview]
Message-ID: <20150629064008.GA16251@gmail.com> (raw)
In-Reply-To: <1435395328.6545.10.camel@gmail.com>
* Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> > This would suggest sensitivity on CPUID details, i.e. that doing
> > fpu__init_system() before other CPU init sequences is causing the bug.
> >
> > Does the patch below perhaps make a difference? (I'd suggest to apply it
> > _without_ the other patch I sent.)
>
> Yup, that made it not care about the BIOS setting.. again.
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 9fc5e3d9d9c8..922c5e0cea4c 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -742,7 +742,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
> > cpu_detect(c);
> > get_cpu_vendor(c);
> > get_cpu_cap(c);
> > - fpu__init_system(c);
> >
> > if (this_cpu->c_early_init)
> > this_cpu->c_early_init(c);
> > @@ -754,6 +753,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
> > this_cpu->c_bsp_init(c);
> >
> > setup_force_cpu_cap(X86_FEATURE_ALWAYS);
> > + fpu__init_system(c);
> > }
Ok, so could you please move the fpu__init_system() further up and see which
position is that starts breaking with the BIOS option set?
here's the current, broken layout of the code:
get_cpu_cap(c);
[0] fpu__init_system(c);
if (this_cpu->c_early_init)
this_cpu->c_early_init(c);
[1]
c->cpu_index = 0;
[2]
filter_cpuid_features(c, false);
[3]
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
[4]
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
[5]
}
and we know it from your testing that moving [0] to [5] fixes the crash.
The question is, can we move it to [4], [3], [2] or even [1] instead, without
breaking the system?
I still don't see where the breakage comes from, but this would help us narrow it
down.
Thanks,
Ingo
next prev parent reply other threads:[~2015-06-29 6:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-27 6:25 regression: massive trouble with fpu rework Mike Galbraith
2015-06-27 8:18 ` [all better] " Mike Galbraith
2015-06-27 8:25 ` Ingo Molnar
2015-06-27 8:55 ` Mike Galbraith
2015-06-27 9:37 ` Borislav Petkov
2015-06-27 11:01 ` Mike Galbraith
2015-06-27 21:02 ` Henrique de Moraes Holschuh
2015-06-28 3:11 ` Mike Galbraith
2015-06-28 15:06 ` Henrique de Moraes Holschuh
2015-06-28 15:39 ` Mike Galbraith
2015-06-29 1:12 ` Henrique de Moraes Holschuh
2015-06-29 6:40 ` Ingo Molnar [this message]
2015-06-29 8:25 ` Mike Galbraith
2015-06-29 8:33 ` Borislav Petkov
2015-06-29 8:41 ` Mike Galbraith
2015-06-29 9:35 ` Ingo Molnar
2015-06-29 9:57 ` Borislav Petkov
2015-06-29 19:48 ` H. Peter Anvin
2015-06-30 5:14 ` Ingo Molnar
2015-06-29 12:27 ` Mike Galbraith
2015-06-29 13:09 ` Borislav Petkov
2015-06-30 5:16 ` Ingo Molnar
2015-06-30 20:22 ` H. Peter Anvin
2015-07-09 13:13 ` Henrique de Moraes Holschuh
2015-06-29 19:50 ` H. Peter Anvin
2015-06-30 5:18 ` Ingo Molnar
2015-06-30 5:24 ` [tip:x86/urgent] x86/fpu: Fix FPU related boot regression when CPUID masking BIOS feature is enabled tip-bot for Ingo Molnar
2015-06-27 8:18 ` regression: massive trouble with fpu rework Ingo Molnar
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=20150629064008.GA16251@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=dave@sr71.net \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=umgwanakikbuti@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.