* 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 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); > > > [0] is the only spot that breaks box. > > 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_MISC_ENABLE_LIMIT_CPUID_BIT) > 0) { > c->cpuid_level = cpuid_eax(0); > get_cpu_cap(c); > } > } > > in early_init_intel(). If you feel like playing, you might comment it > out to see what happens. > > :-)
Indeed, I bet that makes a difference! I wish that 'unmasking' logic came with more comments: - Why do BIOSen ever mask CPUIDs? - Why do we unmask the masking? - Why doesn't the kernel keep on working just fine even if certain CPUID aspects are turned off? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/