Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1173306 > unrolled thread

[all better] Re: regression: massive trouble with fpu rework

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [all better] Re: regression: massive trouble with fpu rework Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-06-27 10:20 +0200
    Re: [all better] Re: regression: massive trouble with fpu rework Ingo Molnar <mingo@kernel.org> - 2015-06-27 10:30 +0200
      Re: [all better] Re: regression: massive trouble with fpu rework Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-06-27 11:00 +0200
        Re: [all better] Re: regression: massive trouble with fpu rework Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2015-06-27 23:10 +0200
          Re: [all better] Re: regression: massive trouble with fpu rework Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2015-06-29 03:20 +0200
        Re: [all better] Re: regression: massive trouble with fpu rework "H. Peter Anvin" <hpa@zytor.com> - 2015-06-30 22:30 +0200

#1173306 — [all better] Re: regression: massive trouble with fpu rework

On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> Hi Ingo,
> 
> My i7-4790 box is having one hell of a time with this merge window, is
> dead in the water.

BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.

	-Mike

--
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/

[toc] | [next] | [standalone]

#1173309

* Mike Galbraith <umgwanakikbuti@gmail.com> wrote:

> On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> > Hi Ingo,
> > 
> > My i7-4790 box is having one hell of a time with this merge window, is
> > dead in the water.
> 
> BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.

Ok, that's interesting. Mind explaining it a bit more verbosely - which setting is 
causing what?

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.)

Thanks,

	Ingo

 arch/x86/kernel/cpu/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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);
 }
 
 void __init early_cpu_init(void)
--
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/

[toc] | [prev] | [next] | [standalone]

#1173316

On Sat, 2015-06-27 at 10:25 +0200, Ingo Molnar wrote:
> * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> 
> > On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> > > Hi Ingo,
> > > 
> > > My i7-4790 box is having one hell of a time with this merge window, is
> > > dead in the water.
> > 
> > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
> 
> Ok, that's interesting. Mind explaining it a bit more verbosely - which setting is 
> causing what?

That BIOS setting is annotated with the helpful text "Disabled for
Windows XP".  It makes box say interesting things during boot, like...

        x86/fpu: XSTATE_CPUID missing!


..or with HEAD, it triggers warning..

        if (boot_cpu_data.cpuid_level < XSTATE_CPUID) {
                WARN_ON_FPU(1);
                return;
        }

..and all kinds of bad juju follows.  I have no idea what the thing does
beyond what I can interpolate from the word 'limit'.

> 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.

> Thanks,
> 
> 	Ingo
> 
>  arch/x86/kernel/cpu/common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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);
>  }
>  
>  void __init early_cpu_init(void)


--
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/

[toc] | [prev] | [next] | [standalone]

#1173415

On Sat, 27 Jun 2015, Mike Galbraith wrote:
> > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
> 
> That BIOS setting is annotated with the helpful text "Disabled for
> Windows XP".  It makes box say interesting things during boot, like...
> 
>         x86/fpu: XSTATE_CPUID missing!
> 
> 
> ..or with HEAD, it triggers warning..
> 
>         if (boot_cpu_data.cpuid_level < XSTATE_CPUID) {
>                 WARN_ON_FPU(1);
>                 return;
>         }
> 
> ..and all kinds of bad juju follows.  I have no idea what the thing does
> beyond what I can interpolate from the word 'limit'.

Well, it is supposed to disable CPUID levels >= 0x04.  This thing should
*NEVER* be enabled, the last operating system that required it to be enabled
was Windows 98.

Can/do we override that crap during cpu init?  If we cannot/don't, maybe
instead of limping along with CPUID crippled, it would be better to either
output a very nasty warning, or outright stop booting [with an appropriate
error message] ?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/

[toc] | [prev] | [next] | [standalone]

#1173600

On Sun, 28 Jun 2015, Mike Galbraith wrote:
> On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote:
> > It is just that this kind of breakage should not be subtle if we can help
> > it, because people will use a crippled system for years without noticing...
> 
> If you can use it without noticing for years, it ain't crippled, or?  My
> point being that severity seems more akin to the box having a zit behind
> its left ear, in which case lobotomizing it seems a tad extreme.

Noted.  However if it does boot with cpuid limited (and we don't "unlimit"
it somehow) on a recent processor, at *best* the user paid good money for a
lot of stuff that is going to not be used to enhance system performance and
system security.

It is not nice to the user to just limp along silently about this.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/

[toc] | [prev] | [next] | [standalone]

#1174748

On 06/29/2015 10:16 PM, Ingo Molnar wrote:
> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
>> On Mon, Jun 29, 2015 at 02:27:23PM +0200, Mike Galbraith wrote:
>>> With it commented out, and fpu__init_system() either back at previously
>>> booting position [5] or at original [0], doesn't matter, box is dead,
>>> but differently.  It stalls after setting clocksource to tsc, and just
>>> sits there.
>>
>> ... which means that unmasking the CPUID features is absolutely needed
>> on Linux. Not unmasking probably triggers this original bug which
>>
>>   066941bd4eeb ("x86: unmask CPUID levels on Intel CPUs")
>>
>> fixed.
> 
> Yes.
> 
> And I'd consider us hanging a separate (but not high prio) bug: the kernel should 
> be robust as long as the CPUID data is stable. In that sense the original fix is 
> right (we really want to unmask all available CPUID leaves), but it also masked 
> another (less severe) kernel bug.
> 
> For example virtualization is known to tweak CPUID details creatively, and 
> firmware (as this example shows it) can mess it up a well, so we generally want to 
> treat it as untrusted input data that needs to be validated.
> 

Well, that is not *entirely* possible, since if the data is just plain
wrong, we're screwed no matter what.

However, we could deal with CPUID level capping.  The best way to do
that is probably to have a table of CPU features and the minimum
required CPUID level for each.  If maximum CPUID level < that level,
disable that feature.

	-hpa


--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web