On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
> On 10 Jan 2006 02:49:13 +0100, Andi Kleen <[email protected]> wrote:
> > Jesper Juhl <[email protected]> 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 <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
