[PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Yinghai Lu]

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
 arch/x86/kernel/cpu/common.c    |  188 ++++++++++++++++++++++------------------
 arch/x86/kernel/cpu/common_64.c |  102 ++++++++++-----------
 2 files changed, 152 insertions(+), 138 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -60,6 +60,18 @@ EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);
 
 __u32 cleared_cpu_caps[NCAPINTS] __cpuinitdata;
 
+/* Current gdt points %fs at the "master" per-cpu area: after this,
+ * it's on the real one. */
+void switch_to_new_gdt(void)
+{
+	struct desc_ptr gdt_descr;
+
+	gdt_descr.address = (long)get_cpu_gdt_table(smp_processor_id());
+	gdt_descr.size = GDT_SIZE - 1;
+	load_gdt(&gdt_descr);
+	asm("mov %0, %%fs" : : "r" (__KERNEL_PERCPU) : "memory");
+}
+
 static int cachesize_override __cpuinitdata = -1;
 static int disable_x86_serial_nr __cpuinitdata = 1;
 
@@ -123,15 +135,15 @@ int __cpuinit get_model_name(struct cpui
 
 void __cpuinit display_cacheinfo(struct cpuinfo_x86 *c)
 {
-	unsigned int n, dummy, ecx, edx, l2size;
+	unsigned int n, dummy, ebx, ecx, edx, l2size;
 
 	n = c->extended_cpuid_level;
 
 	if (n >= 0x80000005) {
-		cpuid(0x80000005, &dummy, &dummy, &ecx, &edx);
+		cpuid(0x80000005, &dummy, &ebx, &ecx, &edx);
 		printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line), D cache %dK (%d bytes/line)\n",
-			edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
-		c->x86_cache_size = (ecx>>24)+(edx>>24);
+				edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
+		c->x86_cache_size = (ecx>>24) + (edx>>24);
 	}
 
 	if (n < 0x80000006)	/* Some chips just has a large L1. */
@@ -185,6 +197,51 @@ static char __cpuinit *table_lookup_mode
 	return NULL;		/* Not found */
 }
 
+#ifdef CONFIG_X86_HT
+void __cpuinit detect_ht(struct cpuinfo_x86 *c)
+{
+	u32 	eax, ebx, ecx, edx;
+	int 	index_msb, core_bits;
+
+	cpuid(1, &eax, &ebx, &ecx, &edx);
+
+	if (!cpu_has(c, X86_FEATURE_HT) || cpu_has(c, X86_FEATURE_CMP_LEGACY))
+		return;
+
+	smp_num_siblings = (ebx & 0xff0000) >> 16;
+
+	if (smp_num_siblings == 1) {
+		printk(KERN_INFO  "CPU: Hyper-Threading is disabled\n");
+	} else if (smp_num_siblings > 1) {
+
+		if (smp_num_siblings > NR_CPUS) {
+			printk(KERN_WARNING "CPU: Unsupported number of siblings %d",
+					smp_num_siblings);
+			smp_num_siblings = 1;
+			return;
+		}
+
+		index_msb = get_count_order(smp_num_siblings);
+		c->phys_proc_id = phys_pkg_id(c->initial_apicid, index_msb);
+
+		printk(KERN_INFO  "CPU: Physical Processor ID: %d\n",
+		       c->phys_proc_id);
+
+		smp_num_siblings = smp_num_siblings / c->x86_max_cores;
+
+		index_msb = get_count_order(smp_num_siblings);
+
+		core_bits = get_count_order(c->x86_max_cores);
+
+		c->cpu_core_id = phys_pkg_id(c->initial_apicid, index_msb) &
+					       ((1 << core_bits) - 1);
+
+		if (c->x86_max_cores > 1)
+			printk(KERN_INFO  "CPU: Processor Core ID: %d\n",
+			       c->cpu_core_id);
+	}
+}
+#endif
 
 static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
 {
@@ -258,7 +315,26 @@ static int __cpuinit have_cpuid_p(void)
 	return flag_is_changeable_p(X86_EFLAGS_ID);
 }
 
-void __init cpu_detect(struct cpuinfo_x86 *c)
+static void __init early_cpu_support_print(void)
+{
+	int i,j;
+	struct cpu_dev *cpu_devx;
+
+	printk("KERNEL supported cpus:\n");
+	for (i = 0; i < X86_VENDOR_NUM; i++) {
+		cpu_devx = cpu_devs[i];
+		if (!cpu_devx)
+			continue;
+		for (j = 0; j < 2; j++) {
+			if (!cpu_devx->c_ident[j])
+				continue;
+			printk("  %s %s\n", cpu_devx->c_vendor,
+				cpu_devx->c_ident[j]);
+		}
+	}
+}
+
+void __cpuinit cpu_detect(struct cpuinfo_x86 *c)
 {
 	/* Get vendor name */
 	cpuid(0x00000000, (unsigned int *)&c->cpuid_level,
@@ -267,16 +343,17 @@ void __init cpu_detect(struct cpuinfo_x8
 	      (unsigned int *)&c->x86_vendor_id[4]);
 
 	c->x86 = 4;
+	/* Intel-defined flags: level 0x00000001 */
 	if (c->cpuid_level >= 0x00000001) {
 		u32 junk, tfms, cap0, misc;
 		cpuid(0x00000001, &tfms, &misc, &junk, &cap0);
-		c->x86 = (tfms >> 8) & 15;
-		c->x86_model = (tfms >> 4) & 15;
+		c->x86 = (tfms >> 8) & 0xf;
+		c->x86_model = (tfms >> 4) & 0xf;
+		c->x86_mask = tfms & 0xf;
 		if (c->x86 == 0xf)
 			c->x86 += (tfms >> 20) & 0xff;
 		if (c->x86 >= 0x6)
-			c->x86_model += ((tfms >> 16) & 0xF) << 4;
-		c->x86_mask = tfms & 15;
+			c->x86_model += ((tfms >> 16) & 0xf) << 4;
 		if (cap0 & (1<<19)) {
 			c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
 			c->x86_clflush_size = ((misc >> 8) & 0xff) * 8;
@@ -341,6 +418,17 @@ static void __init early_identify_cpu(st
 	validate_pat_support(c);
 }
 
+void __init early_cpu_init(void)
+{
+	struct cpu_vendor_dev *cvdev;
+
+	for (cvdev = __x86cpuvendor_start; cvdev < __x86cpuvendor_end; cvdev++)
+		cpu_devs[cvdev->vendor] = cvdev->cpu_dev;
+
+	early_cpu_support_print();
+	early_identify_cpu(&boot_cpu_data);
+}
+
 /*
  * The NOPL instruction is supposed to exist on all CPUs with
  * family >= 6, unfortunately, that's not true in practice because
@@ -500,7 +588,7 @@ static void __cpuinit identify_cpu(struc
 	 */
 	if (c != &boot_cpu_data) {
 		/* AND the already accumulated flags with these */
-		for (i = 0 ; i < NCAPINTS ; i++)
+		for (i = 0; i < NCAPINTS; i++)
 			boot_cpu_data.x86_capability[i] &= c->x86_capability[i];
 	}
 
@@ -529,52 +617,6 @@ void __cpuinit identify_secondary_cpu(st
 	mtrr_ap_init();
 }
 
-#ifdef CONFIG_X86_HT
-void __cpuinit detect_ht(struct cpuinfo_x86 *c)
-{
-	u32 	eax, ebx, ecx, edx;
-	int 	index_msb, core_bits;
-
-	cpuid(1, &eax, &ebx, &ecx, &edx);
-
-	if (!cpu_has(c, X86_FEATURE_HT) || cpu_has(c, X86_FEATURE_CMP_LEGACY))
-		return;
-
-	smp_num_siblings = (ebx & 0xff0000) >> 16;
-
-	if (smp_num_siblings == 1) {
-		printk(KERN_INFO  "CPU: Hyper-Threading is disabled\n");
-	} else if (smp_num_siblings > 1) {
-
-		if (smp_num_siblings > NR_CPUS) {
-			printk(KERN_WARNING "CPU: Unsupported number of the "
-					"siblings %d", smp_num_siblings);
-			smp_num_siblings = 1;
-			return;
-		}
-
-		index_msb = get_count_order(smp_num_siblings);
-		c->phys_proc_id = phys_pkg_id(c->initial_apicid, index_msb);
-
-		printk(KERN_INFO  "CPU: Physical Processor ID: %d\n",
-		       c->phys_proc_id);
-
-		smp_num_siblings = smp_num_siblings / c->x86_max_cores;
-
-		index_msb = get_count_order(smp_num_siblings) ;
-
-		core_bits = get_count_order(c->x86_max_cores);
-
-		c->cpu_core_id = phys_pkg_id(c->initial_apicid, index_msb) &
-					       ((1 << core_bits) - 1);
-
-		if (c->x86_max_cores > 1)
-			printk(KERN_INFO  "CPU: Processor Core ID: %d\n",
-			       c->cpu_core_id);
-	}
-}
-#endif
-
 static __init int setup_noclflush(char *arg)
 {
 	setup_clear_cpu_cap(X86_FEATURE_CLFLSH);
@@ -592,17 +634,17 @@ void __cpuinit print_cpu_info(struct cpu
 		vendor = c->x86_vendor_id;
 
 	if (vendor && strncmp(c->x86_model_id, vendor, strlen(vendor)))
-		printk("%s ", vendor);
+		printk(KERN_CONT "%s ", vendor);
 
-	if (!c->x86_model_id[0])
-		printk("%d86", c->x86);
+	if (c->x86_model_id[0])
+		printk(KERN_CONT "%s", c->x86_model_id);
 	else
-		printk("%s", c->x86_model_id);
+		printk(KERN_CONT "%d86", c->x86);
 
 	if (c->x86_mask || c->cpuid_level >= 0)
-		printk(" stepping %02x\n", c->x86_mask);
+		printk(KERN_CONT " stepping %02x\n", c->x86_mask);
 	else
-		printk("\n");
+		printk(KERN_CONT "\n");
 }
 
 static __init int setup_disablecpuid(char *arg)
@@ -618,16 +660,6 @@ __setup("clearcpuid=", setup_disablecpui
 
 cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;
 
-void __init early_cpu_init(void)
-{
-	struct cpu_vendor_dev *cvdev;
-
-	for (cvdev = __x86cpuvendor_start; cvdev < __x86cpuvendor_end; cvdev++)
-		cpu_devs[cvdev->vendor] = cvdev->cpu_dev;
-
-	early_identify_cpu(&boot_cpu_data);
-}
-
 /* Make sure %fs is initialized properly in idle threads */
 struct pt_regs * __cpuinit idle_regs(struct pt_regs *regs)
 {
@@ -636,18 +668,6 @@ struct pt_regs * __cpuinit idle_regs(str
 	return regs;
 }
 
-/* Current gdt points %fs at the "master" per-cpu area: after this,
- * it's on the real one. */
-void switch_to_new_gdt(void)
-{
-	struct desc_ptr gdt_descr;
-
-	gdt_descr.address = (long)get_cpu_gdt_table(smp_processor_id());
-	gdt_descr.size = GDT_SIZE - 1;
-	load_gdt(&gdt_descr);
-	asm("mov %0, %%fs" : : "r" (__KERNEL_PERCPU) : "memory");
-}
-
 /*
  * cpu_init() initializes state that is per-CPU. Some data is already
  * initialized (naturally) in the bootstrap process, such as the GDT
Index: linux-2.6/arch/x86/kernel/cpu/common_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common_64.c
+++ linux-2.6/arch/x86/kernel/cpu/common_64.c
@@ -103,9 +103,8 @@ void __cpuinit display_cacheinfo(struct
 
 	if (n >= 0x80000005) {
 		cpuid(0x80000005, &dummy, &ebx, &ecx, &edx);
-		printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line), "
-		       "D cache %dK (%d bytes/line)\n",
-		       edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
+		printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line), D cache %dK (%d bytes/line)\n",
+				edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
 		c->x86_cache_size = (ecx>>24) + (edx>>24);
 		/* On K8 L1 TLB is inclusive, so don't count it */
 		c->x86_tlbsize = 0;
@@ -146,8 +145,8 @@ void __cpuinit detect_ht(struct cpuinfo_
 	} else if (smp_num_siblings > 1) {
 
 		if (smp_num_siblings > NR_CPUS) {
-			printk(KERN_WARNING "CPU: Unsupported number of "
-			       "siblings %d", smp_num_siblings);
+			printk(KERN_WARNING "CPU: Unsupported number of siblings %d",
+					smp_num_siblings);
 			smp_num_siblings = 1;
 			return;
 		}
@@ -185,7 +184,7 @@ static void __cpuinit get_cpu_vendor(str
 		if (cpu_devs[i]) {
 			if (!strcmp(v, cpu_devs[i]->c_ident[0]) ||
 			    (cpu_devs[i]->c_ident[1] &&
-			    !strcmp(v, cpu_devs[i]->c_ident[1]))) {
+			     !strcmp(v, cpu_devs[i]->c_ident[1]))) {
 				c->x86_vendor = i;
 				this_cpu = cpu_devs[i];
 				return;
@@ -220,39 +219,6 @@ static void __init early_cpu_support_pri
 	}
 }
 
-/*
- * The NOPL instruction is supposed to exist on all CPUs with
- * family >= 6, unfortunately, that's not true in practice because
- * of early VIA chips and (more importantly) broken virtualizers that
- * are not easy to detect.  Hence, probe for it based on first
- * principles.
- *
- * Note: no 64-bit chip is known to lack these, but put the code here
- * for consistency with 32 bits, and to make it utterly trivial to
- * diagnose the problem should it ever surface.
- */
-static void __cpuinit detect_nopl(struct cpuinfo_x86 *c)
-{
-	const u32 nopl_signature = 0x888c53b1; /* Random number */
-	u32 has_nopl = nopl_signature;
-
-	clear_cpu_cap(c, X86_FEATURE_NOPL);
-	if (c->x86 >= 6) {
-		asm volatile("\n"
-			     "1:      .byte 0x0f,0x1f,0xc0\n" /* nopl %eax */
-			     "2:\n"
-			     "        .section .fixup,\"ax\"\n"
-			     "3:      xor %0,%0\n"
-			     "        jmp 2b\n"
-			     "        .previous\n"
-			     _ASM_EXTABLE(1b,3b)
-			     : "+a" (has_nopl));
-
-		if (has_nopl == nopl_signature)
-			set_cpu_cap(c, X86_FEATURE_NOPL);
-	}
-}
-
 void __cpuinit cpu_detect(struct cpuinfo_x86 *c)
 {
 	/* Get vendor name */
@@ -261,6 +227,7 @@ void __cpuinit cpu_detect(struct cpuinfo
 	      (unsigned int *)&c->x86_vendor_id[8],
 	      (unsigned int *)&c->x86_vendor_id[4]);
 
+	c->x86 = 4;
 	/* Intel-defined flags: level 0x00000001 */
 	if (c->cpuid_level >= 0x00000001) {
 		u32 junk, tfms, cap0, misc;
@@ -271,12 +238,9 @@ void __cpuinit cpu_detect(struct cpuinfo
 		if (c->x86 == 0xf)
 			c->x86 += (tfms >> 20) & 0xff;
 		if (c->x86 >= 0x6)
-			c->x86_model += ((tfms >> 16) & 0xF) << 4;
+			c->x86_model += ((tfms >> 16) & 0xf) << 4;
 		if (cap0 & (1<<19))
 			c->x86_clflush_size = ((misc >> 8) & 0xff) * 8;
-	} else {
-		/* Have CPUID level 0 only - unheard of */
-		c->x86 = 4;
 	}
 }
 
@@ -286,9 +250,6 @@ static void __cpuinit get_cpu_cap(struct
 	u32 tfms, xlvl;
 	u32 ebx;
 
-	/* Initialize the standard set of capabilities */
-	/* Note that the vendor-specific code below might override */
-
 	/* Intel-defined flags: level 0x00000001 */
 	if (c->cpuid_level >= 0x00000001) {
 		u32 capability, excap;
@@ -364,6 +325,39 @@ void __init early_cpu_init(void)
 	early_identify_cpu(&boot_cpu_data);
 }
 
+/*
+ * The NOPL instruction is supposed to exist on all CPUs with
+ * family >= 6, unfortunately, that's not true in practice because
+ * of early VIA chips and (more importantly) broken virtualizers that
+ * are not easy to detect.  Hence, probe for it based on first
+ * principles.
+ *
+ * Note: no 64-bit chip is known to lack these, but put the code here
+ * for consistency with 32 bits, and to make it utterly trivial to
+ * diagnose the problem should it ever surface.
+ */
+static void __cpuinit detect_nopl(struct cpuinfo_x86 *c)
+{
+	const u32 nopl_signature = 0x888c53b1; /* Random number */
+	u32 has_nopl = nopl_signature;
+
+	clear_cpu_cap(c, X86_FEATURE_NOPL);
+	if (c->x86 >= 6) {
+		asm volatile("\n"
+			     "1:      .byte 0x0f,0x1f,0xc0\n" /* nopl %eax */
+			     "2:\n"
+			     "        .section .fixup,\"ax\"\n"
+			     "3:      xor %0,%0\n"
+			     "        jmp 2b\n"
+			     "        .previous\n"
+			     _ASM_EXTABLE(1b,3b)
+			     : "+a" (has_nopl));
+
+		if (has_nopl == nopl_signature)
+			set_cpu_cap(c, X86_FEATURE_NOPL);
+	}
+}
+
 static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
 {
 	c->extended_cpuid_level = 0;
@@ -451,7 +445,7 @@ static void __cpuinit identify_cpu(struc
 
 }
 
-void __cpuinit identify_boot_cpu(void)
+void __init identify_boot_cpu(void)
 {
 	identify_cpu(&boot_cpu_data);
 }
@@ -463,13 +457,6 @@ void __cpuinit identify_secondary_cpu(st
 	mtrr_ap_init();
 }
 
-static __init int setup_noclflush(char *arg)
-{
-	setup_clear_cpu_cap(X86_FEATURE_CLFLSH);
-	return 1;
-}
-__setup("noclflush", setup_noclflush);
-
 struct msr_range {
 	unsigned min;
 	unsigned max;
@@ -513,6 +500,13 @@ static __init int setup_show_msr(char *a
 }
 __setup("show_msr=", setup_show_msr);
 
+static __init int setup_noclflush(char *arg)
+{
+	setup_clear_cpu_cap(X86_FEATURE_CLFLSH);
+	return 1;
+}
+__setup("noclflush", setup_noclflush);
+
 void __cpuinit print_cpu_info(struct cpuinfo_x86 *c)
 {
 	if (c->x86_model_id[0])

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Ingo Molnar]

applied these patches to tip/x86/cpu:

 0a488a5: x86: move 32bit related functions together
 01b2e16: x86: make get_mode_name of 64bit the same as 32bit
 a0854a4: x86: make 32bit support show_msr like 64 bit
 10a434f: x86: remove cpu_vendor_dev
 9d31d35: x86: order functions in cpu/common.c and cpu/common_64.c v2
 3da99c9: x86: make (early)_identify_cpu more the same between 32bit and 64 bit
 5031088: x86: delay early cpu initialization until cpuid is done
 5fef55f: x86: move mtrr cpu cap setting early in early_init_xxxx

thanks Yinghai!

	Ingo

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> applied these patches to tip/x86/cpu:
> 
>  0a488a5: x86: move 32bit related functions together
>  01b2e16: x86: make get_mode_name of 64bit the same as 32bit
>  a0854a4: x86: make 32bit support show_msr like 64 bit
>  10a434f: x86: remove cpu_vendor_dev
>  9d31d35: x86: order functions in cpu/common.c and cpu/common_64.c v2
>  3da99c9: x86: make (early)_identify_cpu more the same between 32bit and 64 bit
>  5031088: x86: delay early cpu initialization until cpuid is done
>  5fef55f: x86: move mtrr cpu cap setting early in early_init_xxxx

hm, something in your patch series is early-crashing tip/master with 
this config:

 http://redhat.com/~mingo/misc/config-Thu_Sep__4_21_23_20_CEST_2008.bad

the early-RIP is 0xffffffff804365b0:

ffffffff8043656a <proc_bus_pci_release>:

ffffffff804365b0:       be d0 00 00 00          mov    $0xd0,%esi
ffffffff804365b5:       e8 ad 28 e7 ff          callq  ffffffff802a8e67 <kmem_cache_alloc>

fault 0xd, general protection fault. Given that it's an immediate 
constant load, something really serious happened.

i've pushed out the broken tree into tip/tmp.master.broken (havent 
updated tip/master with the breakage). I've removed the broken printk in 
kernel/resource.c that Andrew found, see commit 06e44f6af324 - so that's 
not the cause.

	Ingo

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> hm, something in your patch series is early-crashing tip/master with 
> this config:
> 
>  http://redhat.com/~mingo/misc/config-Thu_Sep__4_21_23_20_CEST_2008.bad
> 
> the early-RIP is 0xffffffff804365b0:
> 
> ffffffff8043656a <proc_bus_pci_release>:
> 
> ffffffff804365b0:       be d0 00 00 00          mov    $0xd0,%esi
> ffffffff804365b5:       e8 ad 28 e7 ff          callq  ffffffff802a8e67 <kmem_cache_alloc>
> 
> fault 0xd, general protection fault. Given that it's an immediate 
> constant load, something really serious happened.

ah, that's _another_ -tip testbox that broke at the same time, with a 
different kernel image. The RIP that corresponds to this box is 
0xffffffff80420470:

ffffffff8042045b <strnlen>:
ffffffff8042045b:       55                      push   %rbp

ffffffff80420470:       80 38 00                cmpb   $0x0,(%rax)


which could be consistent with the printk messup ...

> i've pushed out the broken tree into tip/tmp.master.broken (havent 
> updated tip/master with the breakage). I've removed the broken printk 
> in kernel/resource.c that Andrew found, see commit 06e44f6af324 - so 
> that's not the cause.

i've double checked that 06e44f6af324 is applied. I'll bisect this.

	Ingo

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Yinghai Lu]

On Thu, Sep 4, 2008 at 12:41 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> hm, something in your patch series is early-crashing tip/master with
>> this config:
>>
>>  http://redhat.com/~mingo/misc/config-Thu_Sep__4_21_23_20_CEST_2008.bad
>>
>> the early-RIP is 0xffffffff804365b0:
>>
>> ffffffff8043656a <proc_bus_pci_release>:
>>
>> ffffffff804365b0:       be d0 00 00 00          mov    $0xd0,%esi
>> ffffffff804365b5:       e8 ad 28 e7 ff          callq  ffffffff802a8e67 <kmem_cache_alloc>
>>
>> fault 0xd, general protection fault. Given that it's an immediate
>> constant load, something really serious happened.
>
> ah, that's _another_ -tip testbox that broke at the same time, with a
> different kernel image. The RIP that corresponds to this box is
> 0xffffffff80420470:
>
> ffffffff8042045b <strnlen>:
> ffffffff8042045b:       55                      push   %rbp
>
> ffffffff80420470:       80 38 00                cmpb   $0x0,(%rax)
>
>
> which could be consistent with the printk messup ...
>
>> i've pushed out the broken tree into tip/tmp.master.broken (havent
>> updated tip/master with the breakage). I've removed the broken printk
>> in kernel/resource.c that Andrew found, see commit 06e44f6af324 - so
>> that's not the cause.
>
> i've double checked that 06e44f6af324 is applied. I'll bisect this.
>
or by
ca81beb4a340ee690803fcb1498f863d0e68843f

YH

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > i've pushed out the broken tree into tip/tmp.master.broken (havent 
> > updated tip/master with the breakage). I've removed the broken 
> > printk in kernel/resource.c that Andrew found, see commit 
> > 06e44f6af324 - so that's not the cause.
> 
> i've double checked that 06e44f6af324 is applied. I'll bisect this.

bisection came up with:

 # good: [8bfd9710] Merge branch 'x86/xsave'
 # bad:  [06e44f6a] IO resources: fix/remove printk
 # good: [282a5f84] Merge branch 'irq/sparseirq'
 # bad:  [a0854a46] x86: make 32bit support show_msr like 64 bit
 # good: [5031088d] x86: delay early cpu initialization until cpuid is
 # good: [9d31d35b] x86: order functions in cpu/common.c and cpu/commo
 # bad:  [10a434fc] x86: remove cpu_vendor_dev

| 10a434fcb23a57c385177a0086955fae01003f64 is first bad commit
| commit 10a434fcb23a57c385177a0086955fae01003f64
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date:   Thu Sep 4 21:09:45 2008 +0200
|
|     x86: remove cpu_vendor_dev

and the thing is, 10a434fc is way too big:

| 15 files changed, 106 insertions(+), 106 deletions(-)

and it's not obvious at first (neither at second) sight what the problem 
is. You really need to start doing much smaller patches for such 
critical/hard-to-debug code areas.

	Ingo

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Yinghai Lu]

On Thu, Sep 4, 2008 at 1:04 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> > i've pushed out the broken tree into tip/tmp.master.broken (havent
>> > updated tip/master with the breakage). I've removed the broken
>> > printk in kernel/resource.c that Andrew found, see commit
>> > 06e44f6af324 - so that's not the cause.
>>
>> i've double checked that 06e44f6af324 is applied. I'll bisect this.
>
> bisection came up with:
>
>  # good: [8bfd9710] Merge branch 'x86/xsave'
>  # bad:  [06e44f6a] IO resources: fix/remove printk
>  # good: [282a5f84] Merge branch 'irq/sparseirq'
>  # bad:  [a0854a46] x86: make 32bit support show_msr like 64 bit
>  # good: [5031088d] x86: delay early cpu initialization until cpuid is
>  # good: [9d31d35b] x86: order functions in cpu/common.c and cpu/commo
>  # bad:  [10a434fc] x86: remove cpu_vendor_dev
>
> | 10a434fcb23a57c385177a0086955fae01003f64 is first bad commit
> | commit 10a434fcb23a57c385177a0086955fae01003f64
> | Author: Yinghai Lu <yhlu.kernel@gmail.com>
> | Date:   Thu Sep 4 21:09:45 2008 +0200
> |
> |     x86: remove cpu_vendor_dev
>
> and the thing is, 10a434fc is way too big:
>
> | 15 files changed, 106 insertions(+), 106 deletions(-)
>
> and it's not obvious at first (neither at second) sight what the problem
> is. You really need to start doing much smaller patches for such
> critical/hard-to-debug code areas.
>
could be alignment again...

YH

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Yinghai Lu]

On Thu, Sep 4, 2008 at 1:07 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Thu, Sep 4, 2008 at 1:04 PM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> * Ingo Molnar <mingo@elte.hu> wrote:
>>
>>> > i've pushed out the broken tree into tip/tmp.master.broken (havent
>>> > updated tip/master with the breakage). I've removed the broken
>>> > printk in kernel/resource.c that Andrew found, see commit
>>> > 06e44f6af324 - so that's not the cause.
>>>
>>> i've double checked that 06e44f6af324 is applied. I'll bisect this.
>>
>> bisection came up with:
>>
>>  # good: [8bfd9710] Merge branch 'x86/xsave'
>>  # bad:  [06e44f6a] IO resources: fix/remove printk
>>  # good: [282a5f84] Merge branch 'irq/sparseirq'
>>  # bad:  [a0854a46] x86: make 32bit support show_msr like 64 bit
>>  # good: [5031088d] x86: delay early cpu initialization until cpuid is
>>  # good: [9d31d35b] x86: order functions in cpu/common.c and cpu/commo
>>  # bad:  [10a434fc] x86: remove cpu_vendor_dev
>>
>> | 10a434fcb23a57c385177a0086955fae01003f64 is first bad commit
>> | commit 10a434fcb23a57c385177a0086955fae01003f64
>> | Author: Yinghai Lu <yhlu.kernel@gmail.com>
>> | Date:   Thu Sep 4 21:09:45 2008 +0200
>> |
>> |     x86: remove cpu_vendor_dev
>>
>> and the thing is, 10a434fc is way too big:
>>
>> | 15 files changed, 106 insertions(+), 106 deletions(-)
>>
>> and it's not obvious at first (neither at second) sight what the problem
>> is. You really need to start doing much smaller patches for such
>> critical/hard-to-debug code areas.
>>
> could be alignment again...

ffffffff80d86c20 d __cpu_dev_amd_cpu_dev
ffffffff80d86c20 A __x86_cpu_dev_start
ffffffff80d86c28 d __dyn_array_ptr_irq_2_pin_head
ffffffff80d86c28 D __dyn_array_start
ffffffff80d86c30 d __dyn_array_ptr_irq_cfgx
ffffffff80d86c38 d __dyn_array_ptr_sparse_irqs
ffffffff80d86c40 D __dyn_array_end
ffffffff80d86c40 d __initcall_selinux_init
ffffffff80d86c40 D __per_cpu_dyn_array_end
ffffffff80d86c40 D __per_cpu_dyn_array_start
ffffffff80d86c40 D __security_initcall_start
ffffffff80d86c48 R __parainstructions
ffffffff80d86c48 D __security_initcall_end
ffffffff80d86c48 A __x86_cpu_dev_end

don't know how could the linker squash others tables into cpu_dev
pointer array..

YH

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Yinghai Lu]

On Thu, Sep 4, 2008 at 1:32 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Thu, Sep 4, 2008 at 1:07 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> On Thu, Sep 4, 2008 at 1:04 PM, Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>> * Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>>> > i've pushed out the broken tree into tip/tmp.master.broken (havent
>>>> > updated tip/master with the breakage). I've removed the broken
>>>> > printk in kernel/resource.c that Andrew found, see commit
>>>> > 06e44f6af324 - so that's not the cause.
>>>>
>>>> i've double checked that 06e44f6af324 is applied. I'll bisect this.
>>>
>>> bisection came up with:
>>>
>>>  # good: [8bfd9710] Merge branch 'x86/xsave'
>>>  # bad:  [06e44f6a] IO resources: fix/remove printk
>>>  # good: [282a5f84] Merge branch 'irq/sparseirq'
>>>  # bad:  [a0854a46] x86: make 32bit support show_msr like 64 bit
>>>  # good: [5031088d] x86: delay early cpu initialization until cpuid is
>>>  # good: [9d31d35b] x86: order functions in cpu/common.c and cpu/commo
>>>  # bad:  [10a434fc] x86: remove cpu_vendor_dev
>>>
>>> | 10a434fcb23a57c385177a0086955fae01003f64 is first bad commit
>>> | commit 10a434fcb23a57c385177a0086955fae01003f64
>>> | Author: Yinghai Lu <yhlu.kernel@gmail.com>
>>> | Date:   Thu Sep 4 21:09:45 2008 +0200
>>> |
>>> |     x86: remove cpu_vendor_dev
>>>
>>> and the thing is, 10a434fc is way too big:
>>>
>>> | 15 files changed, 106 insertions(+), 106 deletions(-)
>>>
>>> and it's not obvious at first (neither at second) sight what the problem
>>> is. You really need to start doing much smaller patches for such
>>> critical/hard-to-debug code areas.
>>>
>> could be alignment again...
>
> ffffffff80d86c20 d __cpu_dev_amd_cpu_dev
> ffffffff80d86c20 A __x86_cpu_dev_start
> ffffffff80d86c28 d __dyn_array_ptr_irq_2_pin_head
> ffffffff80d86c28 D __dyn_array_start
> ffffffff80d86c30 d __dyn_array_ptr_irq_cfgx
> ffffffff80d86c38 d __dyn_array_ptr_sparse_irqs
> ffffffff80d86c40 D __dyn_array_end
> ffffffff80d86c40 d __initcall_selinux_init
> ffffffff80d86c40 D __per_cpu_dyn_array_end
> ffffffff80d86c40 D __per_cpu_dyn_array_start
> ffffffff80d86c40 D __security_initcall_start
> ffffffff80d86c48 R __parainstructions
> ffffffff80d86c48 D __security_initcall_end
> ffffffff80d86c48 A __x86_cpu_dev_end
>
> don't know how could the linker squash others tables into cpu_dev
> pointer array..

it seems there is some merging problem.. please check

index 192f6d8..30973db 100644
--- a/arch/x86/kernel/vmlinux_64.lds.S
+++ b/arch/x86/kernel/vmlinux_64.lds.S
@@ -172,11 +172,11 @@ SECTIONS
   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
        *(.x86_cpu_dev.init)
   }
+  __x86_cpu_dev_end = .;

   DYN_ARRAY_INIT(8)

   SECURITY_INIT
-  __x86_cpu_dev_end = .;

   . = ALIGN(8);
   .parainstructions : AT(ADDR(.parainstructions) - LOAD_OFFSET) {

YH

Re: [PATCH] x86: order functions in cpu/common.c and cpu/common_64.c

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> On Thu, Sep 4, 2008 at 1:32 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> > On Thu, Sep 4, 2008 at 1:07 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >> On Thu, Sep 4, 2008 at 1:04 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >>>
> >>> * Ingo Molnar <mingo@elte.hu> wrote:
> >>>
> >>>> > i've pushed out the broken tree into tip/tmp.master.broken (havent
> >>>> > updated tip/master with the breakage). I've removed the broken
> >>>> > printk in kernel/resource.c that Andrew found, see commit
> >>>> > 06e44f6af324 - so that's not the cause.
> >>>>
> >>>> i've double checked that 06e44f6af324 is applied. I'll bisect this.
> >>>
> >>> bisection came up with:
> >>>
> >>>  # good: [8bfd9710] Merge branch 'x86/xsave'
> >>>  # bad:  [06e44f6a] IO resources: fix/remove printk
> >>>  # good: [282a5f84] Merge branch 'irq/sparseirq'
> >>>  # bad:  [a0854a46] x86: make 32bit support show_msr like 64 bit
> >>>  # good: [5031088d] x86: delay early cpu initialization until cpuid is
> >>>  # good: [9d31d35b] x86: order functions in cpu/common.c and cpu/commo
> >>>  # bad:  [10a434fc] x86: remove cpu_vendor_dev
> >>>
> >>> | 10a434fcb23a57c385177a0086955fae01003f64 is first bad commit
> >>> | commit 10a434fcb23a57c385177a0086955fae01003f64
> >>> | Author: Yinghai Lu <yhlu.kernel@gmail.com>
> >>> | Date:   Thu Sep 4 21:09:45 2008 +0200
> >>> |
> >>> |     x86: remove cpu_vendor_dev
> >>>
> >>> and the thing is, 10a434fc is way too big:
> >>>
> >>> | 15 files changed, 106 insertions(+), 106 deletions(-)
> >>>
> >>> and it's not obvious at first (neither at second) sight what the problem
> >>> is. You really need to start doing much smaller patches for such
> >>> critical/hard-to-debug code areas.
> >>>
> >> could be alignment again...
> >
> > ffffffff80d86c20 d __cpu_dev_amd_cpu_dev
> > ffffffff80d86c20 A __x86_cpu_dev_start
> > ffffffff80d86c28 d __dyn_array_ptr_irq_2_pin_head
> > ffffffff80d86c28 D __dyn_array_start
> > ffffffff80d86c30 d __dyn_array_ptr_irq_cfgx
> > ffffffff80d86c38 d __dyn_array_ptr_sparse_irqs
> > ffffffff80d86c40 D __dyn_array_end
> > ffffffff80d86c40 d __initcall_selinux_init
> > ffffffff80d86c40 D __per_cpu_dyn_array_end
> > ffffffff80d86c40 D __per_cpu_dyn_array_start
> > ffffffff80d86c40 D __security_initcall_start
> > ffffffff80d86c48 R __parainstructions
> > ffffffff80d86c48 D __security_initcall_end
> > ffffffff80d86c48 A __x86_cpu_dev_end
> >
> > don't know how could the linker squash others tables into cpu_dev
> > pointer array..
> 
> it seems there is some merging problem.. please check
> 
> index 192f6d8..30973db 100644
> --- a/arch/x86/kernel/vmlinux_64.lds.S
> +++ b/arch/x86/kernel/vmlinux_64.lds.S
> @@ -172,11 +172,11 @@ SECTIONS
>    .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
>         *(.x86_cpu_dev.init)
>    }
> +  __x86_cpu_dev_end = .;
> 
>    DYN_ARRAY_INIT(8)
> 
>    SECURITY_INIT
> -  __x86_cpu_dev_end = .;
> 
>    . = ALIGN(8);
>    .parainstructions : AT(ADDR(.parainstructions) - LOAD_OFFSET) {

indeed, that was my fault and it probably explains the crash i was 
seeing - thanks!

	Ingo