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,
>>> b
* 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 clocksour
* 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.
>
> > - W
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 hav
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,
> MSR_IA32_
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 cur
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] fpu__init
* 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 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 wit
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 enab
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
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 missi
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 fpu__init_s
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 C
* 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. Mi
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 "uns
25 matches
Mail list logo
