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


Groups > linux.kernel > #1522224

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

From Boris Ostrovsky <boris.ostrovsky@oracle.com>
Newsgroups linux.kernel
Subject Re: [PATCH] x86/cpuid: Deal with broken firmware once more
Date 2016-11-15 02:30 +0100
Message-ID <sDAJr-6BC-15@gated-at.bofh.it> (permalink)
References (13 earlier) <sBZ9g-7QM-27@gated-at.bofh.it> <sBZCi-83k-21@gated-at.bofh.it> <sCOEO-8el-21@gated-at.bofh.it> <sD7ob-3On-17@gated-at.bofh.it> <sDcH7-7b1-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:

> I found out that my domU kernels invoke the 'apic_disable' function
> because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
> which would cause the 'smp_found_config' bit to be unset at boot-up.


smp_found_config is not the problem, it is usually zero for Xen PV guests.

What is the problem is that because of your particular config selection 
acpi_mps_check() fails (with the error message that you mention below) 
and that leads to X86_FEATURE_APIC being cleared. And then we indeed 
switch to APIC noop and things go south after that.

-boris

>
> This would cause 'init_apic_mappings' to call 'apic_disable', which
> would cause Xen's 'apic' ops structure pointer to be replaced with the
> no-op APIC ops structure's pointer.
>
> The use of the no-op APIC ops structure would in turn cause invalid
> virtual CPU package identifiers to be generated. Invalid CPU package
> identifiers would in turn cause the RAPL module to produce a kernel oops
> due to potentially missing error handling.
>
> It looks like I have been ignoring the following kernel warning which I
> should have noticed a long time ago:
>
>   MPS support code is not built-in.
>   Using acpi=off or acpi=noirq or pci=noacpi may have problem
>
> To all on this e-mail thread, I learned a bit through this exercise, but
> I have also taken a lot of everyone's time and created quite a bit of
> e-mail traffic because of a kernel configuration issue on my end.
>
> My apologies.
>
> Vefa
>

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] x86/cpuid: Deal with broken firmware once more "M. Vefa Bicakci" <m.v.b@runbox.com> - 2016-11-12 23:10 +0100
  Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-13 19:10 +0100
    Re: [PATCH] x86/cpuid: Deal with broken firmware once more "M. Vefa Bicakci" <m.v.b@runbox.com> - 2016-11-14 00:50 +0100
      Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-15 02:30 +0100
        Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-18 12:20 +0100
          Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-18 15:30 +0100

csiph-web