Messages in this thread Patch in this message | | | From | Andi Kleen <> | Subject | Re: Athlon 64 X2 cpuinfo oddities | Date | Tue, 10 Jan 2006 03:36:31 +0100 |
| |
On Tuesday 10 January 2006 03:12, Jesper Juhl wrote: > On 10 Jan 2006 02:49:13 +0100, Andi Kleen <ak@suse.de> wrote: > > Jesper Juhl <jesper.juhl@gmail.com> writes: > > > > > > Well, first of all you'll notice that the second core shows a > > > "physical id" of 127 while the first core shows an id of 0. Shouldn't > > > the second core be id 1, just like the "core id" fields are 0 & 1? > > > > In theory it could be an uninitialized phys_proc_id (0xff >> 1), > > but it could be also the BIOS just setting the local APIC of CPU 1 > > to 0xff for some reason. > > > > If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()]) > > at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does > > dmesg | grep PHYSCPU output? > > > Not a thing since I'm using arch/i386 here (32bit distribution > (Slackware), just building a 32bit kernel optimized for K8).
Ah - how legacy.
> But, I stuck that printk into identify_cpu() in > arch/i386/kernel/cpu/common.c instead, and this is what I get : > $ dmesg | grep PHYSCPU > [ 30.323965] PHYSCPU 0 0 > [ 30.402588] PHYSCPU 1 7f
Hmm it looks like the phys_proc_id initialization is at the wrong place in 32bit. early_cpu_detect is only called on the BP, not on the AP. early_intel_workaround is also there incorrectly. Might be a mismerge - it should be one function below.
The appended patch should help, but it's untested.
> > > > > > > Second thing I find slightly odd is the lack of "sse3" in the "flags" list. > > > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3? > > > Is it a case of: > > > a) Me being wrong, not all Athlon 64 X2's feature SSE3? > > > b) The CPU actually featuring SSE3 but Linux not taking advantage of it? > > > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo > > > doesn't show that fact? > > > d) Something else? > > > > It's called pni (prescott new instructions) for historical reasons. We added > > the bit too early before Intel's marketing department could make up its > > mind fully, so Linux is stuck with the old codename. > > > Does anything actually parse the /proc/cpuinfo flags field? are we > really stuck with it?
Do you really want to find out by a report from a rightfully annoyed user? I considered at some point to print sse3 in addition to pni, but then it seemed like too much bloat for only a cosmetical issue. Maybe if it becomes a popular FAQ, but it isn't that far yet.
(I can just see the headlines for such a patch - "Linux 2.6.20 finally adding SSE3 support")
-Andi
i386: Move phys_proc_id/early intel workaround to correct function.
early_cpu_detect only runs on the BP, but this code needs to run on all CPUs.
Looks like a mismerge somewhere. Also add a warning comment.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/arch/i386/kernel/cpu/common.c =================================================================== --- linux.orig/arch/i386/kernel/cpu/common.c +++ linux/arch/i386/kernel/cpu/common.c @@ -204,7 +204,10 @@ static int __devinit have_cpuid_p(void) /* Do minimum CPU detection early. Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment. - The others are not touched to avoid unwanted side effects. */ + The others are not touched to avoid unwanted side effects. + + WARNING: this function is only called on the BP. Don't add code here + that is supposed to run on all CPUs. */ static void __init early_cpu_detect(void) { struct cpuinfo_x86 *c = &boot_cpu_data; @@ -236,12 +239,6 @@ static void __init early_cpu_detect(void if (cap0 & (1<<19)) c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8; } - - early_intel_workaround(c); - -#ifdef CONFIG_X86_HT - phys_proc_id[smp_processor_id()] = (cpuid_ebx(1) >> 24) & 0xff; -#endif } void __devinit generic_identify(struct cpuinfo_x86 * c) @@ -289,6 +286,12 @@ void __devinit generic_identify(struct c get_model_name(c); /* Default name */ } } + + early_intel_workaround(c); + +#ifdef CONFIG_X86_HT + phys_proc_id[smp_processor_id()] = (cpuid_ebx(1) >> 24) & 0xff; +#endif } static void __devinit squash_the_stupid_serial_number(struct cpuinfo_x86 *c) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |