[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |