diff options
author | Baoquan He <bhe@redhat.com> | 2014-05-05 08:48:26 +0400 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2014-05-16 18:27:35 +0400 |
commit | c401eb8ee374a5fc2b56042c0072ce51a0beb0dc (patch) | |
tree | 43e58ee0105b47e20dd93961bf14e8c27bfb793e /fs/signalfd.c | |
parent | 247dba58a19a34f01c363b3aec4d2c21cfb87d8e (diff) | |
download | linux-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 'fs/signalfd.c')
0 files changed, 0 insertions, 0 deletions