Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1522224
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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