On Tue, 30 Jun 2015, Ingo Molnar wrote:
> 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
>
On Tue, 30 Jun 2015, Ingo Molnar wrote:
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
On 06/29/2015 10:16 PM, Ingo Molnar wrote:
>
> * Borislav Petkov 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,
>>>
On 06/29/2015 10:16 PM, Ingo Molnar wrote:
* Borislav Petkov b...@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,
* H. Peter Anvin wrote:
> On 06/28/2015 11:40 PM, Ingo Molnar wrote:
> >
> > 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:
> >
> >
* Borislav Petkov 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
* H. Peter Anvin wrote:
> On 06/29/2015 02:35 AM, Ingo Molnar wrote:
> >
> > Indeed, I bet that makes a difference!
> >
> > I wish that 'unmasking' logic came with more comments:
> >
> > - Why do BIOSen ever mask CPUIDs?
> >
>
> To work around bugs in legacy operating systems.
>
> > -
On 06/28/2015 11:40 PM, Ingo Molnar wrote:
>
> 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);
On 06/29/2015 02:35 AM, Ingo Molnar wrote:
>
> Indeed, I bet that makes a difference!
>
> I wish that 'unmasking' logic came with more comments:
>
> - Why do BIOSen ever mask CPUIDs?
>
To work around bugs in legacy operating systems.
> - Why do we unmask the masking?
Because we don't
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.
On Mon, 2015-06-29 at 10:33 +0200, Borislav Petkov wrote:
> I bet it is that
>
> /* Unmask CPUID levels if masked: */
> if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
> if (msr_clear_bit(MSR_IA32_MISC_ENABLE,
>
On Mon, Jun 29, 2015 at 11:35:04AM +0200, Ingo Molnar wrote:
> I wish that 'unmasking' logic came with more comments:
>
> - Why do BIOSen ever mask CPUIDs?
Doesn't say a thing why:
066941bd4eeb ("x86: unmask CPUID levels on Intel CPUs")
SDM doesn't say why either:
"Limit CPUID Maxval (R/W)
* Borislav Petkov wrote:
> On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
> > On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
> > > *
> > > Ok, so could you please move the fpu__init_system() further up and see
> > > which
> > > position is that starts breaking with the
On Mon, 2015-06-29 at 10:33 +0200, Borislav Petkov wrote:
> On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
> > On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
> > > *
> > > Ok, so could you please move the fpu__init_system() further up and see
> > > which
> > > position is
On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
> On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
> > *
> > 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
On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
> *
> 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]
* 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.)
>
>
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.
...
On Mon, Jun 29, 2015 at 11:35:04AM +0200, Ingo Molnar wrote:
I wish that 'unmasking' logic came with more comments:
- Why do BIOSen ever mask CPUIDs?
Doesn't say a thing why:
066941bd4eeb (x86: unmask CPUID levels on Intel CPUs)
SDM doesn't say why either:
Limit CPUID Maxval (R/W)
When
On Mon, 2015-06-29 at 10:33 +0200, Borislav Petkov wrote:
I bet it is that
/* Unmask CPUID levels if masked: */
if (c-x86 6 || (c-x86 == 6 c-x86_model = 0xd)) {
if (msr_clear_bit(MSR_IA32_MISC_ENABLE,
* Borislav Petkov b...@alien8.de wrote:
On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
*
Ok, so could you please move the fpu__init_system() further up and see
which
position is that starts breaking with the
On 06/28/2015 11:40 PM, Ingo Molnar wrote:
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);
On 06/29/2015 02:35 AM, Ingo Molnar wrote:
Indeed, I bet that makes a difference!
I wish that 'unmasking' logic came with more comments:
- Why do BIOSen ever mask CPUIDs?
To work around bugs in legacy operating systems.
- Why do we unmask the masking?
Because we don't have those
On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
*
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
* Mike Galbraith umgwanakikb...@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
On Mon, 2015-06-29 at 10:33 +0200, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
*
Ok, so could you please move the fpu__init_system() further up and see
which
position is that starts
On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
*
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]
* H. Peter Anvin h...@zytor.com wrote:
On 06/29/2015 02:35 AM, Ingo Molnar wrote:
Indeed, I bet that makes a difference!
I wish that 'unmasking' logic came with more comments:
- Why do BIOSen ever mask CPUIDs?
To work around bugs in legacy operating systems.
- Why do
* Borislav Petkov b...@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
* H. Peter Anvin h...@zytor.com wrote:
On 06/28/2015 11:40 PM, Ingo Molnar wrote:
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:
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
On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 28 Jun 2015, Mike Galbraith wrote:
> > > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
> > >
> > > Well, it is supposed to disable CPUID levels >= 0x04. This thing should
> > > *NEVER* be
On Sun, 28 Jun 2015, Mike Galbraith wrote:
> > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
> >
> > 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
On Sun, 28 Jun 2015, Mike Galbraith wrote:
BIOS setting Limit CPUID Maximum upsets new fpu code mightily.
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
On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote:
On Sun, 28 Jun 2015, Mike Galbraith wrote:
BIOS setting Limit CPUID Maximum upsets new fpu code mightily.
Well, it is supposed to disable CPUID levels = 0x04. This thing should
*NEVER* be enabled, the last
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
On Sat, 2015-06-27 at 18:02 -0300, Henrique de Moraes Holschuh wrote:
> 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
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
On Sat, 2015-06-27 at 11:37 +0200, Borislav Petkov wrote:
> On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
> > Yup, that made it not care about the BIOS setting.. again.
>
> Does it say
>
> "x86/fpu: Legacy x87 FPU detected."
>
> with Ingo's patch?
Nope.
> Or do you see
On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
> Yup, that made it not care about the BIOS setting.. again.
Does it say
"x86/fpu: Legacy x87 FPU detected."
with Ingo's patch?
Or do you see that "x86/fpu: Enabled xstate features... " print out from
the end of
On Sat, 2015-06-27 at 10:25 +0200, Ingo Molnar wrote:
> * Mike Galbraith 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
* Mike Galbraith 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.
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
On Sat, 2015-06-27 at 10:25 +0200, Ingo Molnar wrote:
* Mike Galbraith umgwanakikb...@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
On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
Yup, that made it not care about the BIOS setting.. again.
Does it say
x86/fpu: Legacy x87 FPU detected.
with Ingo's patch?
Or do you see that x86/fpu: Enabled xstate features... print out from
the end of
* Mike Galbraith umgwanakikb...@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
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
On Sat, 2015-06-27 at 11:37 +0200, Borislav Petkov wrote:
On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
Yup, that made it not care about the BIOS setting.. again.
Does it say
x86/fpu: Legacy x87 FPU detected.
with Ingo's patch?
Nope.
Or do you see that
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!
On Sat, 2015-06-27 at 18:02 -0300, Henrique de Moraes Holschuh wrote:
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
50 matches
Mail list logo
