Core2 misidentification with 4 core Xeon
mabshoff
following popped up:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
stepping : 6
cpu MHz : 2666.840
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm pni monitor ds_cpl est tm2 cx16 xtpr
bogomips : 5332.75
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
With Jason's Core2 detection code that we currently use in Sage's gmp
package the above CPU is not identified as a Core2. But it is
certainly a derivative or am I getting something wrong here.
I do remember that issues with gmp 4.2.2 and Core2 detection being
discussed here before, so maybe somebody already has a solution.
Cheers,
Michael
Bill Hart
this machine and see if it reports core2.
You'll need config.guess and friends (config.sub, configfsf.guess and
configfsf.sub and possibly some other files) from the main directory
of the mpir source tree.
Bill.
Bill Hart
Bill.
On 10/06/2008, Bill Hart <goodwi...@googlemail.com> wrote:
> Currently xeon doesn't appear to be dealt with specifically by mpir,
> so what happens will depend on how the machine is identified by
> config.guess.
>
> It's not clear to me that all Xeon's should be identified as core 2
> machines. Perhaps they should by default be identified as pentium 4
> with mmx and sse2, though I don't see why Jason's patches wouldn't run
> on all Xeons. Perhaps Jason has a comment about this.
>
>
> Bill.
mabshoff
On Jun 10, 2:32 pm, "Bill Hart" <goodwillh...@googlemail.com> wrote:
> We currently don't use Jason's script. Could you run config.guess on
> this machine and see if it reports core2.
> You'll need config.guess and friends (config.sub, configfsf.guess and
> configfsf.sub and possibly some other files) from the main directory
> of the mpir source tree.
box I have to ask the guy who reported that issue to look into it.
> Bill.
Cheers,
Michael
> On 10/06/2008, mabshoff <Michael.Absh...@mathematik.uni-dortmund.de> wrote:
>
>
>
> > Inhttps://groups.google.com/group/sage-support/t/3371db245e33a79cthe
Bill Hart
so what happens will depend on how the machine is identified by
config.guess.
It's not clear to me that all Xeon's should be identified as core 2
machines. Perhaps they should by default be identified as pentium 4
with mmx and sse2, though I don't see why Jason's patches wouldn't run
on all Xeons. Perhaps Jason has a comment about this.
Bill.
On 10/06/2008, Bill Hart <goodwi...@googlemail.com> wrote:
Gonzalo Tornaria
> processor : 2
> vendor_id : GenuineIntel
> cpu family : 6
> model : 7
It should be model = 17h (old kernel?).
There's a list of processors in pp. 21--23 of
http://download.intel.com/design/processor/applnots/24161832.pdf
family = 6 / model = 7 is a pentium III or pentium III Xeon
But this is a core 2 extreme or xeon, 45nm: family = 6 / model = 17h
My patch for core2 detection only checks up to model = 15 (core2), but
it does compute family and model using extended fields.
Just add another case to the code for family = 6:
model = 0x16 ==> celeron model 16h (65 nm)
model = 0x17 ==> core 2 extreme or xeon model 17h (45 nm)
These are the only two models above 15 (decimal) in the chart referenced above.
Gonzalo
Jason Martin
values reported for core2 chips with both the quad cores and the
"extreme" editions. Does anyone happen to have machines with those
types of chips that they could give me access to (running Linux or
OSX)?
Thanks,
jason
--
Jason Worth Martin
Asst. Professor of Mathematics
http://www.math.jmu.edu/~martin
Gonzalo Tornaria
> > We currently don't use Jason's script. Could you run config.guess on
> > this machine and see if it reports core2.
>
>
> Allegedly it does reports "pentium3-unknown-linux-gnu"
yes, that's what should do if it computes family = 6 // model = 7
(ignoring the extended model field).
> > You'll need config.guess and friends (config.sub, configfsf.guess and
> > configfsf.sub and possibly some other files) from the main directory
> > of the mpir source tree.
>
>
> That was with gmp-4.2.2.spkg, but since I do not have access to that
> box I have to ask the guy who reported that issue to look into it.
For the sage spkg, you may use some portions of the code in my patch
to 4.2.1, which I reattach (to compute extended family and model) plus
the change I suggested in my previous post (check for model 0x16 and
0x17).
Gonzalo
Gonzalo Tornaria
http://processorfinder.intel.com/details.aspx?sSpec=SLANU
Gonzalo
mabshoff
On Jun 10, 3:02 pm, "Gonzalo Tornaria" <torna...@math.utexas.edu>
wrote:
> On 6/10/08, mabshoff <Michael.Absh...@mathematik.uni-dortmund.de> wrote:
Hi Gonzalo,
> > processor : 2
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 7
>
> It should be model = 17h (old kernel?).
kernel. But RedHat is known to patch their enterprise kernels rather
heavily and since Centos builds from RHEL sources with insignificant
changes (Redhat->Centos in many places like the documentation for
copyright reasons) we can assume that the old kernel is a factor
here.
> There's a list of processors in pp. 21--23 ofhttp://download.intel.com/design/processor/applnots/24161832.pdf
> family = 6 / model = 7 is a pentium III or pentium III Xeon
>
> But this is a core 2 extreme or xeon, 45nm: family = 6 / model = 17h
>
> My patch for core2 detection only checks up to model = 15 (core2), but
> it does compute family and model using extended fields.
>
> Just add another case to the code for family = 6:
>
> model = 0x16 ==> celeron model 16h (65 nm)
> model = 0x17 ==> core 2 extreme or xeon model 17h (45 nm)
>
> These are the only two models above 15 (decimal) in the chart referenced above.
>
> Gonzalo
I am pointing the gut to this thread so he can hopefully give direct
input.
Cheers,
Michael
Bill Hart
any luck it now correctly identifies Celeron model 16 and Core 2 model
17.
Perhaps if the guy would like to see if mpir correctly identifies his
machine. Config.guess seems to have its own assembly code for getting
the CPUID, so perhaps it won't suffer from the kernel problem
mentioned.
Bill.
On 10/06/2008, mabshoff <Michael...@mathematik.uni-dortmund.de> wrote:
>
>
>
Jason Martin
Are you going to take care of fixing this then? I'm happy for you to
do so. I was just going to modify the C code "here" file in
config.guess to include the new extended family IDs.
--jason
--
Jason Martin
--jason
Bill Hart
information. If it does, it should do the right thing with it now.
It looks like it does, as the code says:
model = ((fms >> 4) & 15) + ((fms >> 12) & 0xf0);
which looks like it has 32 bits not 16 for the model number.
Bill.
Bill Hart
Bill.
On 10/06/2008, Bill Hart <goodwi...@googlemail.com> wrote:
lciti
I am the guy with the beast at hand.
The system-wide config.guess that comes from
$ which config.guess
/opt/globus/sbin/config.guess
and the output is:
$ config.guess
x86_64-unknown-linux-gnu
I must admit I do not know how to run the .sub scripts, I try to
guess.
The gmp (sage) ones as well as the vanilla ones (ftp.sunet.se/pub/gnu/
gmp/gmp-4.2.2.tar.gz) give:
$ ./config.guess
pentium3-unknown-linux-gnu
$ ./config.sub $(./config.guess)
pentium3-unknown-linux-gnu
$ ./configfsf.guess
x86_64-unknown-linux-gnu
$ ./configfsf.sub $(./configfsf.guess)
x86_64-unknown-linux-gnu
I tried applying the patch above but unsuccessfully.
Applied to gmp-4.2.2 (sage and vanilla):
patch < /tmp/patch.guess
patching file config.guess
Hunk #1 FAILED at 654.
Hunk #2 succeeded at 692 with fuzz 2 (offset 17 lines).
Hunk #4 FAILED at 724.
2 out of 4 hunks FAILED -- saving rejects to file config.guess.rej
Applied to gmp-4.2.1 (vanilla):
patch < /tmp/patch.guess
patching file config.guess
Hunk #1 FAILED at 654.
Hunk #2 succeeded at 675 with fuzz 2.
Hunk #4 FAILED at 724.
2 out of 4 hunks FAILED -- saving rejects to file config.guess.rej
GMP is not one of the packages of sage I am going to use so often,
but if there is something more I can try I am happy to help.
Cheers,
Luca
Bill Hart
"core". At present mpir won't recognise this. Actually configure will
just abort on a core machine. We should fix this.
Bill.
On 10 Jun, 23:36, "Bill Hart" <goodwillh...@googlemail.com> wrote:
> Hmm, that would be 8 bits not 4, which should be right.
>
> Bill.
>
>
> > I didn't check that config.guess actually gets the extended cpuid
> > information. If it does, it should do the right thing with it now.
>
> > It looks like it does, as the code says:
>
> > model = ((fms >> 4) & 15) + ((fms >> 12) & 0xf0);
>
> > which looks like it has 32 bits not 16 for the model number.
>
> > Bill.
>
>
> > > Okay, ignore this... I crossed Bill's last post in the aether.
>
> > > --jason
>
> > > On Tue, Jun 10, 2008 at 6:26 PM, Jason Martin
>
>
> > > > Hi Gonzalo,
>
> > > > Are you going to take care of fixing this then? I'm happy for you to
> > > > do so. I was just going to modify the C code "here" file in
> > > > config.guess to include the new extended family IDs.
>
> > > > --jason
>
> > > > On Tue, Jun 10, 2008 at 6:18 PM, mabshoff
lciti
output=0x10676
steppingID=6
modelID=7
familyID=6
proc_type=0
ext_modelID=1
ext_familyID=0
but the program prints "No"
lciti
http://wstein.org/home/wbhart/mpir-1.0.0/configfsf.guess
http://wstein.org/home/wbhart/mpir-1.0.0/config.guess
$ ./config.guess
x86_64-unknown-linux-gnu
Bill Hart
I entered the wrong values in config.guess. I must have been half
asleep. Can you try again. Here is a link to the file:
http://sage.math.washington.edu/home/wbhart/mpir-1.0.0/config.guess
Regards,
Bill Hart.
On 11 Jun, 01:26, lciti <knul...@yahoo.com> wrote:
> Downloadinghttp://wstein.org/home/wbhart/mpir-1.0.0/configfsf.guesshttp://wstein.org/home/wbhart/mpir-1.0.0/config.guess
> $ ./config.guess
> x86_64-unknown-linux-gnu
lciti
You were almost there.
$ ./config.guess
x86_64-unknown-linux-gnu
but if you patch it as appended you obtain what you want.
You must have been three-quarters asleep :-D
$ ./config.guess
core2-unknown-linux-gnu
Thanks.
Cheers,
Luca
--- config.guess.old 2008-06-11 11:52:49.000000000 +0100
+++ config.guess 2008-06-11 12:09:42.000000000 +0100
@@ -727,7 +727,7 @@
else if (model <= 13) modelstr = "pentium3";
else if (model == 14) modelstr = "core";
else if (model == 15) modelstr = "core2"; // 64 bits
- else if (model == 22) modelstr = "pentium2"
+ else if (model == 22) modelstr = "pentium2";
else if (model == 23) modelstr = "core2"; // 64 bits
else modelstr = "p6???";
break;
Bill Hart
Regards,
Bill Hart.
Gonzalo Tornaria
> OK, I figured this out. On page 22 of the intel documentation Gonzalo
> linked to, it actually says that family 6 model 7 is Core 2 Extreme or
> Xeon model 17.
Actually, family 6 model 7 is pentium III model 7. The core 2 quad is
really model 0x17, but you don't see the first hex digit if you don't
check the extended family. I did patch the code to include the
extended family, but I didn't add model 0x16 or 0x17 to the if cases.
> So it is actually reporting correctly. What is wrong is
> that config.guess has *completely the wrong* strings for the CPUID's.
> I don't understand why the person who wrote the file just put all
> models from 7-13 as the same thing, when they aren't. I'll fix this
Before my patch, all models 7 and up were reported as pentium 3; I
kept all 7-13 as pentium3, added model 14 (core) and model 15 (core2),
but I didn't add model 22 (celeron) or model 23 (core2 - 45nm). The
complete list of processors for family 6, from intel documentation,
seems to be:
reported as "pentiumpro":
model 1 = pentium pro
reported as "pentium2":
model 3 = pentium II model 03, pentium II overdrive
model 5 = pentium II, xeon, celeron model 05
model 6 = celeron model 06
reported as "pentium3":
model 7 = pentium III model 07
model 8 = pentium III model 08
model 9 = pentium M, celeron M model 9
model 10 = pentium III Xeon, model 0Ah
model 11 = pentium III model 0Bh
model 13 = pentium M, celeron M model 0Dh
reported as "core":
model 14 = core duo, core solo model 0Eh
reported as "core2":
model 15 = core 2 duo, quad, extreme, xeon model 0Fh (65nm)
reported as "pentium2" (you added this)
model 22 = celeron model 16h
reported as "core2" (you added this)
model 22 = core 2 extreme, xeon model 17h (45nm)
It's not clear to me what is the best thing to report in each case.
For instance, celeron is a brand name, just like xeon. It might be the
case that celeron model 16h is some sort of "core 2 celeron" ??? And
maybe model 14 (core) should be reported as "pentium3"?
I have similar doubts with family 15 (pentium 4). All of them are
pentium 4 or pentium D; some are 32 bit and some are 64 bit. I
arbitrarily decided that 0, 1, 2, 3 were "pentium4" and that 4 and 6
were "pentiumD", and attempted to use this difference to mean "32 bit"
and "64 bit" respectively. All of this is wild guessing, and I don't
know if it makes sense to differentiate between those two, as long as
the configure script recognizes that the processor is 64 bit.
Maybe processors should be differentiated if they have different
tuning options for gcc (-mtune and -march command line options).
The man page for gcc-4.3 lists the following:
(it's not included in debian, I guess even the man page is now
non-free!, http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options)
- pentium3, pentium3m (mmx + sse)
- pentium-m (pentium 3 based, mmx + sse + sse2)
- pentium4, pentium4m (mmx + sse + sse2)
- prescott (pentium4 based, mmx + sse + sse2 + sse3)
- nocona (pentium4 based, 64 bit, mmx + sse + sse2 + sse3)
- core2 (64 bit, mmx + sse + sse2 + sse3 + ssse3)
Best, Gonzalo
Bill Hart
Ignore that post of mine. I realised it was rubbish as soon as I
posted it, and removed it from the list.
Thanks for the extra info though. I think we can do much better with
getting the identification right. Essentially since the new FSF
config.guess is ver 3+ we can just write our own, which means we can
be a little more specific about processor identification, i.e. there
wouldn't be anything wrong with having config.guess return celeron and
have the configure file actually deal with celeron as whatever, i.e.
we could have a slightly finer breakdown if we wanted.
Currently the result of config.guess seems to be canonicalised into a
pretty limited range of processors and configure does some pretty
haphazard stuff based on that canonicalised name. I think things are
probably improved somewhat in GMP 4.2.2, but it's not really a
sustainable way of organising assembly support I don't think.
Bill.
Gonzalo Tornaria
> Thanks for the extra info though. I think we can do much better with
> getting the identification right. Essentially since the new FSF
> config.guess is ver 3+ we can just write our own, which means we can
> be a little more specific about processor identification, i.e. there
> wouldn't be anything wrong with having config.guess return celeron and
> have the configure file actually deal with celeron as whatever, i.e.
> we could have a slightly finer breakdown if we wanted.
Yes, but note that "celeron" is a bad example, because it means so
many different things, it would be as useless as returning "xeon", and
almost as useless as returning
"some-pentium-but-I-won't-tell-you-which-one" for all pentium
processors.
Best, Gonzalo
Bill Hart
Actually I put the Celeron with model number 22 down as a Pentium II.
We should probably check that this is correct. As you say, it could be
anything.
Bill.
On Jun 11, 2:25 pm, "Gonzalo Tornaria" <torna...@math.utexas.edu>
wrote:
mabshoff
On Jun 11, 9:54 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> Ha ha, yes!!
>
> Actually I put the Celeron with model number 22 down as a Pentium II.
> We should probably check that this is correct. As you say, it could be
> anything.
to report the specific core architecture used if that is possible. It
would certainly be some work to get this right, but in the end it
should be well worth it :)
> Bill.
Cheers,
Michael