Re: 2.6.25-mm1: not looking good


* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

WARNING: at arch/x86/kernel/genapic_64.c:86 read_apic_id+0x31/0x67()

[<ffffffff803523e6>] ? debug_smp_processor_id+0x32/0xc4
[<ffffffff8021ede5>] read_apic_id+0x31/0x67
[<ffffffff8066f7f2>] verify_local_APIC+0xa7/0x163
[<ffffffff8066e837>] native_smp_prepare_cpus+0x1ed/0x301
[<ffffffff80669ab2>] kernel_init+0x5a/0x276

that came in via the UV-APIC patchset but the warning is entirely
harmless. At that point we've got a single CPU running only so
preemption of that code to another CPU is not possible.

native_smp_prepare_cpus() should probably just disable preemption, that
way we could remove all those ugly preempt disable-enable calls from the
called functions - per the patch below. (not boot tested yet - might
provoke atomic-scheduling warnings if i forgot about some schedule point
in this rather large codepath)

Ingo

------------------->
Subject: x86: disable preemption in native_smp_prepare_cpus
From: Ingo Molnar <mingo@xxxxxxx>
Date: Fri Apr 18 11:07:10 CEST 2008

Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
arch/x86/kernel/smpboot.c | 2 ++
1 file changed, 2 insertions(+)

Index: linux-x86.q/arch/x86/kernel/smpboot.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/smpboot.c
+++ linux-x86.q/arch/x86/kernel/smpboot.c
@@ -1181,6 +1181,7 @@ static void __init smp_cpu_index_default
*/
void __init native_smp_prepare_cpus(unsigned int max_cpus)
{
+ preempt_disable();
nmi_watchdog_default();
smp_cpu_index_default();
current_cpu_data = boot_cpu_data;
@@ -1237,6 +1238,7 @@ void __init native_smp_prepare_cpus(unsi
printk(KERN_INFO "CPU%d: ", 0);
print_cpu_info(&cpu_data(0));
setup_boot_clock();
+ preempt_enable();
}
/*
* Early setup to make printk work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC 3/3] SGI Altix cross partition memory (XPMEM)
    ... WARNING: declaring multiple variables together should be avoided ... the code is fine as is even with preemption configured on. ... it can't be moved to another CPU via ...
    (Linux-Kernel)
  • Re: [RFC 3/3] SGI Altix cross partition memory (XPMEM)
    ... WARNING: declaring multiple variables together should be avoided ... The WARNING #3 above "declaring multiple variables together should be avoided". ... the code is fine as is even with preemption configured on. ... it can't be moved to another CPU via ...
    (Linux-Kernel)
  • Re: [RFC 3/3] SGI Altix cross partition memory (XPMEM)
    ... Dean Nelson wrote: ... What warning does it generate here? ... the code is fine as is even with preemption configured on. ... it can't be moved to another CPU via ...
    (Linux-Kernel)
  • Re: consistent hard lockup with recent kernels
    ... it is most likely bugs uncovered by native preemption. ... WARNING: Kernel preemption is disabled, expect reduced performance. ... etc.) when the system is under load (most notably with disk load). ...
    (freebsd-current)
  • Re: [RFC 3/3] SGI Altix cross partition memory (XPMEM)
    ... Dean Nelson wrote: ... WARNING: declaring multiple variables together should be avoided ... The WARNING #3 above "declaring multiple variables together should be avoided". ... the code is fine as is even with preemption configured on. ...
    (Linux-Kernel)