x86: fix x2apic preenabled system with kexec
in [Kernel]
|
Prev: xfs: convert inode shrinker to per-filesystem contexts
Next: [PATCH v2] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers
From: Suresh Siddha on 15 Jul 2010 14:20 On Thu, 2010-07-15 at 00:00 -0700, Yinghai Lu wrote: > Found one x2apic system kexec loop test failed > when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip) > > first kernel can kexec second kernel, but second kernel can not kexec third one. > > it can be duplicated on another system with BIOS preenabled x2apic. > First kernel can not kexec second kernel. > > It turns out, when kernel boot with pre-enabled x2apic, it will not execute > disable_local_APIC on shutdown path. > > when init_apic_mappings() is called in setup_arch, it will skip setting of > apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic()) > Then later, disable_local_APIC() will bail out early because !apic_phys. > > So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys. Thanks for the nice debug work! As we still have NMI enabled, it looks like we get a NMI during kexec and as we reset gdt/idt before kexec launch, we might get a triple fault causing the system to reboot. > another solution could be updating init_apic_mappings() to set apic_phys even > for preenabled x2apic system. Actually even for x2apic system, that lapic > address is mapped already in early stage. Below patch is the right one. We should probably unmap apic_phys mapping when x2apic is enabled by the OS. > BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? I am not sure. There might be one. Is there any bug which can't handle this condition? > > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > Cc: stable(a)kernel.org For this patch: Acked-by: Suresh Siddha <suresh.b.siddha(a)intel.com> > --- > arch/x86/kernel/apic/apic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6/arch/x86/kernel/apic/apic.c > =================================================================== > --- linux-2.6.orig/arch/x86/kernel/apic/apic.c > +++ linux-2.6/arch/x86/kernel/apic/apic.c > @@ -921,7 +921,7 @@ void disable_local_APIC(void) > unsigned int value; > > /* APIC hasn't been mapped yet */ > - if (!apic_phys) > + if (!x2apic_mode && !apic_phys) > return; > > clear_local_APIC(); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 15 Jul 2010 16:20 On 07/15/2010 11:16 AM, Suresh Siddha wrote: > On Thu, 2010-07-15 at 00:00 -0700, Yinghai Lu wrote: > >> BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? > > I am not sure. There might be one. Is there any bug which can't handle > this condition? We merged apic_ops into struct apic a while ago. so even for system with x2apic preenabled by BIOS, x2apic_cluster/phys is set to apic until smp_pare_cpus()::default_setup_apic_routing() after enable_IR_x2apic. that means the boot cpu x2apic is accessed via memmap instead msr based way at that point. not sure if the Boot apic id is bigger than 255. read_apic() for apic id could be wrong. ( in early_acpi_boot_init, acpi_boot_init, init_apic_mappings) looks like we need to re-read boot_cpu_physical_apicid or we could assign x2apic_cluster/phys in check_x2apic(), and later if intr_remapping can not be enabed, we can revert back to phys_flat or flat? Thanks Yinghai Lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 15 Jul 2010 16:50
On 07/15/2010 01:10 PM, Yinghai Lu wrote: > On 07/15/2010 11:16 AM, Suresh Siddha wrote: >> On Thu, 2010-07-15 at 00:00 -0700, Yinghai Lu wrote: >> >>> BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? >> >> I am not sure. There might be one. Is there any bug which can't handle >> this condition? > > We merged apic_ops into struct apic a while ago. > > so even for system with x2apic preenabled by BIOS, x2apic_cluster/phys is set to apic until smp_pare_cpus()::default_setup_apic_routing() after enable_IR_x2apic. > > that means the boot cpu x2apic is accessed via memmap instead msr based way at that point. > > not sure if the Boot apic id is bigger than 255. read_apic() for apic id could be wrong. ( in early_acpi_boot_init, acpi_boot_init, init_apic_mappings) > > looks like we need to re-read boot_cpu_physical_apicid > or we could assign x2apic_cluster/phys in check_x2apic(), and later if intr_remapping can not be enabed, we can revert back to phys_flat or flat? > never mind, early_acpi_boot_init::acpi_parse_madt::default_acpi_madt_oem_check() will handle the case. it will set the apic to apic_x2apic_... accordingly if x2apic is preenabled. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |