summaryrefslogtreecommitdiff
path: root/reference/C/EXAMPLES/for1.c
AgeCommit message (Collapse)AuthorFilesLines
2008-01-27Initial import (2.0.2-6)2.0.2-6Tobias Klauser1-0/+23
>authorThomas Gleixner <tglx@linutronix.de>2016-10-29 13:42:42 +0200 committerThomas Gleixner <tglx@linutronix.de>2016-10-29 14:00:46 +0200 commit1e90a13d0c3dc94512af1ccb2b6563e8297838fa (patch) treeba8b86dbed5f1e33d6039cfd34b633178b562207 parentc067affcd316a36a28beaf8ea8c39db22a88c778 (diff)
x86/smpboot: Init apic mapping before usage
The recent changes, which forced the registration of the boot cpu on UP systems, which do not have ACPI tables, have been fixed for systems w/o local APIC, but left a wreckage for systems which have neither ACPI nor mptables, but the CPU has an APIC, e.g. virtualbox. The boot process crashes in prefill_possible_map() as it wants to register the boot cpu, which needs to access the local apic, but the local APIC is not yet mapped. There is no reason why init_apic_mapping() can't be invoked before prefill_possible_map(). So instead of playing another silly early mapping game, as the ACPI/mptables code does, we just move init_apic_mapping() before the call to prefill_possible_map(). In hindsight, I should have noticed that combination earlier. Sorry for the churn (also in stable)! Fixes: ff8560512b8d ("x86/boot/smp: Don't try to poke disabled/non-existent APIC") Reported-and-debugged-by: Michal Necasek <michal.necasek@oracle.com> Reported-and-tested-by: Wolfgang Bauer <wbauer@tmo.at> Cc: prarit@redhat.com Cc: ville.syrjala@linux.intel.com Cc: michael.thayer@oracle.com Cc: knut.osmundsen@oracle.com Cc: frank.mehnert@oracle.com Cc: Borislav Petkov <bp@alien8.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat