summaryrefslogtreecommitdiff
path: root/init
diff options
context:
space:
mode:
authorBaoquan He <bhe@redhat.com>2014-05-05 08:48:26 +0400
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2014-05-16 18:27:35 +0400
commitc401eb8ee374a5fc2b56042c0072ce51a0beb0dc (patch)
tree43e58ee0105b47e20dd93961bf14e8c27bfb793e /init
parent247dba58a19a34f01c363b3aec4d2c21cfb87d8e (diff)
downloadlinux-c401eb8ee374a5fc2b56042c0072ce51a0beb0dc.tar.xz
ACPI / processor: Check if LAPIC is present during initialization
In acpi_processor_get_info(), ACPI processor info is initialized including ID, namely CPU index. Currently, on a UP system running an SMP kerenl with no LAPIC in the MADT, cpu0_initialized is checked to decide whether or not the CPU has been initialized. However, this check may not be sufficient for kdump kernels. Most of time only 1 CPU is supported because of known problems in kdump kernels. So say the multiple CPUs are present in the boot kernel and a crash happens on one specific CPU, say CPU2. Then it jumps into the kdump kernel with "nr_cpus=1" in the command line. In this situation, the kdump kernel will reuse the ACPI resources from the crashed kernel directly. That means all LAPIC instances are enabled in the MADT while only one CPU is in use. In the kdump kernel, x86_cpu_to_apicid contains the correct APIC ID and it's related to the CPU ID. If cpu0_initialized is checked only, 0 will be used as the CPU index instead of that APIC ID, which is not correct. In addition to checking cpu0_initialized, check acpi_lapic. If acpi_lapic is 0, then no LAPIC is available from the MADT and the system should be treated as a UP one without a LAPIC (that is, assign 0 to the CPU index). Otherwise, use the original (valid) CPU index. Signed-off-by: Baoquan He <bhe@redhat.com> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions