search for: do_boot_cpu

>From: Tristan Gingold [mailto:Tristan.Gingold@bull.net] >Sent: 2006年4月21日 15:26 >> > >> >See how we solve this on x86 near the top of do_boot_cpu() in >> >arch/x86/smpboot.c. Essentially we allocate extra idle domains on >> >demand to give us enough idle vcpus for one per physical cpu. >> > >> > -- Keir >> >> Yes, that''s the same story on ia64 where we also allocate idle >> vcpu...

...> >> But the logical limit of the IA64 Max CPU is larger than 64. >> If someone change these values, some possibility make this error >again. >> >> To avoid this problem, I believe this check code should be exists. > >See how we solve this on x86 near the top of do_boot_cpu() in >arch/x86/smpboot.c. Essentially we allocate extra idle domains on >demand to give us enough idle vcpus for one per physical cpu. > > -- Keir Yes, that''s the same story on ia64 where we also allocate idle vcpu at do_boot_cpu(). That''s why I''m not sure...

.../kernel/smpboot.c =================================================================== --- linux-2.6.14-rc1.orig/arch/i386/kernel/smpboot.c 2005-09-20 20:38:22.000000000 -0700 +++ linux-2.6.14-rc1/arch/i386/kernel/smpboot.c 2005-09-28 12:54:08.000000000 -0700 @@ -898,7 +898,8 @@ static int __devinit do_boot_cpu(int api * This grunge runs the startup process for * the targeted processor. */ - cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); + if (!cpu_gdt_descr[cpu].address) + cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); atomic_set(&init_deasser...

...Gingold@bull.net] >Sent: 2006年4月21日 15:40 > >Le Vendredi 21 Avril 2006 09:28, Tian, Kevin a écrit : >> From: Tristan Gingold [mailto:Tristan.Gingold@bull.net] >> >> >Sent: 2006年4月21日 15:26 >> > >> >> >See how we solve this on x86 near the top of do_boot_cpu() in >> >> >arch/x86/smpboot.c. Essentially we allocate extra idle domains on >> >> >demand to give us enough idle vcpus for one per physical cpu. >> >> > >> >> > -- Keir >> >> >> >> Yes, that''s the same s...

.../kernel/smpboot.c =================================================================== --- linux-2.6.14-rc1.orig/arch/i386/kernel/smpboot.c 2005-09-20 20:38:22.000000000 -0700 +++ linux-2.6.14-rc1/arch/i386/kernel/smpboot.c 2005-09-28 12:54:08.000000000 -0700 @@ -898,7 +898,8 @@ static int __devinit do_boot_cpu(int api * This grunge runs the startup process for * the targeted processor. */ - cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); + if (!cpu_gdt_descr[cpu].address) + cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); atomic_set(&init_deasser...

I am trying to build xen on x86_64 SLES 9 SP2 box this morning and am getting this error: arch/xen/kernel/built-in.o(.text+0x1bd6): In function `__do_suspend'': : undefined reference to `HYPERVISOR_vcpu_pickle'' make[4]: *** [.tmp_vmlinux1] Error 1 make[4]: Leaving directory `/tmp/xen-unstable.hg/linux-2.6.12-xen0'' make[3]: *** [build] Error 2 make[3]: Leaving directory

I just did a yum update on a CentOS 7 / Xen 4.6 server which took me from kernel-3.18.34-20.el7.x86_64 -> kernel-3.18.44-20.el7.x86_64 After rebooting, the following notice is printed immediately upon xl create'ing a domain: libxl: notice: libxl_numa.c:499:libxl__get_numa_candidate: NUMA placement failed, performance might be affected Indeed performance is significantly degraded. This

.../kernel/smpboot.c =================================================================== --- linux-2.6.14-rc1.orig/arch/i386/kernel/smpboot.c 2005-09-20 20:19:57.000000000 -0700 +++ linux-2.6.14-rc1/arch/i386/kernel/smpboot.c 2005-09-20 20:38:22.000000000 -0700 @@ -898,6 +898,7 @@ static int __devinit do_boot_cpu(int api * This grunge runs the startup process for * the targeted processor. */ + cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); atomic_set(&init_deasserted, 0); Index: linux-2.6.14-rc1/arch/i386/kernel/head.S ================================================...

.../kernel/smpboot.c =================================================================== --- linux-2.6.14-rc1.orig/arch/i386/kernel/smpboot.c 2005-09-20 20:19:57.000000000 -0700 +++ linux-2.6.14-rc1/arch/i386/kernel/smpboot.c 2005-09-20 20:38:22.000000000 -0700 @@ -898,6 +898,7 @@ static int __devinit do_boot_cpu(int api * This grunge runs the startup process for * the targeted processor. */ + cpu_gdt_descr[cpu].address = __get_free_page(GFP_KERNEL|__GFP_ZERO); atomic_set(&init_deasserted, 0); Index: linux-2.6.14-rc1/arch/i386/kernel/head.S ================================================...

Solved. For the archives: Noticed in xl info output that only 1 core was recognised, even though nr_cpus should show 16 on this box. Tried rebooting and selecting the old .34 kernel, console printed "smpboot: do_boot_cpu failed(-1) to wakeup CPU#1" and CentOS failed to boot. Powered down the box fully and started back up with the latest .44 kernel and everything is working fine now. Not enough of an expert to know if this is a bug in the kernel, a problem with the BIOS, bad hardware, a completely random stro...

...ot.c =================================================================== --- linux-2.6.14-zach-work.orig/arch/i386/kernel/smpboot.c 2005-11-04 12:12:35.000000000 -0800 +++ linux-2.6.14-zach-work/arch/i386/kernel/smpboot.c 2005-11-04 17:55:00.000000000 -0800 @@ -877,6 +877,12 @@ static int __devinit do_boot_cpu(int api unsigned long start_eip; unsigned short nmi_high = 0, nmi_low = 0; + if (!cpu_gdt_descr[cpu].address && + !(cpu_gdt_descr[cpu].address = get_zeroed_page(GFP_KERNEL))) { + printk("Failed to allocate GDT for CPU %d\n", cpu); + return 1; + } + ++cpucount; /*...

...ot.c =================================================================== --- linux-2.6.14-zach-work.orig/arch/i386/kernel/smpboot.c 2005-11-04 12:12:35.000000000 -0800 +++ linux-2.6.14-zach-work/arch/i386/kernel/smpboot.c 2005-11-04 17:55:00.000000000 -0800 @@ -877,6 +877,12 @@ static int __devinit do_boot_cpu(int api unsigned long start_eip; unsigned short nmi_high = 0, nmi_low = 0; + if (!cpu_gdt_descr[cpu].address && + !(cpu_gdt_descr[cpu].address = get_zeroed_page(GFP_KERNEL))) { + printk("Failed to allocate GDT for CPU %d\n", cpu); + return 1; + } + ++cpucount; /*...

...q %rsi + call early_load_tss + popq %rsi + /* Load IDT */ pushq %rsi call early_load_idt diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 27aa04a95702..fb55d28332e2 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -1040,6 +1040,12 @@ static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle, /* Enable the espfix hack for this CPU */ init_espfix_ap(cpu); + /* Set up GDT_ENTRY_CPUNODE for early exception handling */ + setup_getcpu(cpu); + + /* Setup TSS so that AP can use IST early */ + tss_setup(cpu); + /* So we see what's up */...

...hysical address of the code */ @@ -460,7 +459,7 @@ start_secondary(void *unused) /* external functions not defined in the headers */ extern void calibrate_delay(void); - secondary_cpu_init(); + cpu_init(); /* OK, we're in the routine */ ack_CPI(VIC_CPU_BOOT_CPI); @@ -580,7 +579,7 @@ do_boot_cpu(__u8 cpu) /* init_tasks (in sched.c) is indexed logically */ stack_start.esp = (void *) idle->thread.esp; - init_gdt(cpu, idle); + init_gdt(cpu); irq_ctx_init(cpu); /* Note: Don't modify initial ss override */ @@ -884,8 +883,8 @@ smp_invalidate_interrupt(void) /* This routine...

...hysical address of the code */ @@ -460,7 +459,7 @@ start_secondary(void *unused) /* external functions not defined in the headers */ extern void calibrate_delay(void); - secondary_cpu_init(); + cpu_init(); /* OK, we're in the routine */ ack_CPI(VIC_CPU_BOOT_CPI); @@ -580,7 +579,7 @@ do_boot_cpu(__u8 cpu) /* init_tasks (in sched.c) is indexed logically */ stack_start.esp = (void *) idle->thread.esp; - init_gdt(cpu, idle); + init_gdt(cpu); irq_ctx_init(cpu); /* Note: Don't modify initial ss override */ @@ -884,8 +883,8 @@ smp_invalidate_interrupt(void) /* This routine...

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -