558daa289a
On x86_64 on AMD machines where the first APIC_ID is not zero, we get: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 which means that when the ACPI processor driver loads and tries to parse the _Pxx states it fails to do as, as it ends up calling acpi_get_cpuid which does this: for_each_possible_cpu(i) { if (cpu_physical_id(i) == apic_id) return i; } And the bootup CPU, has not been found so it fails and returns -1 for the first CPU - which then subsequently in the loop that "acpi_processor_get_info" does results in returning an error, which means that "acpi_processor_add" failing and per_cpu(processor) is never set (and is NULL). That means that when xen-acpi-processor tries to load (much much later on) and parse the P-states it gets -ENODEV from acpi_processor_register_performance() (which tries to read the per_cpu(processor)) and fails to parse the data. Reported-by-and-Tested-by: Stefan Bader <stefan.bader@canonical.com> Suggested-by: Boris Ostrovsky <boris.ostrovsky@amd.com> [v2: Bit-shift APIC ID by 24 bits] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
||
---|---|---|
.. | ||
debugfs.c | ||
debugfs.h | ||
enlighten.c | ||
grant-table.c | ||
irq.c | ||
Kconfig | ||
Makefile | ||
mmu.c | ||
mmu.h | ||
multicalls.c | ||
multicalls.h | ||
p2m.c | ||
pci-swiotlb-xen.c | ||
platform-pci-unplug.c | ||
setup.c | ||
smp.c | ||
spinlock.c | ||
suspend.c | ||
time.c | ||
trace.c | ||
vdso.h | ||
vga.c | ||
xen-asm.h | ||
xen-asm.S | ||
xen-asm_32.S | ||
xen-asm_64.S | ||
xen-head.S | ||
xen-ops.h |