Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751850AbbF2GkS (ORCPT ); Mon, 29 Jun 2015 02:40:18 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:35052 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751385AbbF2GkN (ORCPT ); Mon, 29 Jun 2015 02:40:13 -0400 Date: Mon, 29 Jun 2015 08:40:08 +0200 From: Ingo Molnar To: Mike Galbraith Cc: Ingo Molnar , LKML , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , Andy Lutomirski , Denys Vlasenko , Oleg Nesterov , Dave Hansen Subject: Re: [all better] Re: regression: massive trouble with fpu rework Message-ID: <20150629064008.GA16251@gmail.com> References: <1435386316.3664.23.camel@gmail.com> <1435393129.3490.7.camel@gmail.com> <20150627082514.GA10894@gmail.com> <1435395328.6545.10.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1435395328.6545.10.camel@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2104 Lines: 71 * Mike Galbraith 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/