You are not logged in.
Does anyone know if I should be using pentium-M, pentium4, or Core2 Duo for my kernel config for a Core Duo (T2500)? I've searched around but have come up empty handed for any definitive answer (some say pentium-M, others pentium4). /proc/cpuinfo does show the pni flag and family=6. Woud that be similar to that of the Core2 Duo running under a 32-bit profile? Or would it be better to stick with Pentium-M?
Any input would be greatly appreciated.
Last edited by somedrew (2007-06-13 08:17:37)
Offline
Use the "Core2/New Xeon" option. It's the one I use.
- EDIT -
Ahh, wait! I read it wrong. You have a Core Duo, not Core 2 Duo.
Use the Pentium M then.
Last edited by quetzyg (2007-06-13 11:05:14)
ZzZz...
Offline
Thanks!
Offline
well, according to a lenghty gentoo discussion I had about that a long time ago (see link on gentoo's cflags wiki page), intel confirmed that -march=prescott was the way to go for core duos (and 32bit core2duos). translated to kernel family, I guess that makes it p4?
Last edited by lloeki (2007-06-13 14:48:23)
To know recursion, you must first know recursion.
Offline
I have a pentiumD processor in a Gigabyte mobo 81865GME-775-RH with 2.8ghz.
It supports Intel Core 2 duo processors.
Will it run arch64bit OS
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Thanks for the responses! I wasn't sure if the P4 kernel config was for Prescott chips or earlier, or if it really makes a difference. I've tried Pentium-M, P4, and Core2 Duo configs. All worked without any blatant differences (don't feel like fooling around with benchmarks).
Offline
Some quick googling gives a clear answer:
GCC Optimization Flags
Safe, recommended optimizations for GCC 3.4.x and later:
-pipe -O2 -march=prescott -fomit-frame-pointer
Possibly unsafe optimizations for GCC 3.3.x and later:
-mfpmath=sse
Optimizations likely to break binary-only compatibility:
-ffast-math
From the Thinkwiki entry on the Core Duo CPU.
Last edited by B (2007-06-14 03:27:50)
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
Some quick googling gives a clear answer:
GCC Optimization Flags Safe, recommended optimizations for GCC 3.4.x and later: -pipe -O2 -march=prescott -fomit-frame-pointer Possibly unsafe optimizations for GCC 3.3.x and later: -mfpmath=sse Optimizations likely to break binary-only compatibility: -ffast-math
From the Thinkwiki entry on the Core Duo CPU.
Do NOT EVER adjust or use custom cflags on a kernel beyond those available in the kernel config.
It WILL result in a broken kernel, and possibly hardware damage or data loss.
Any config option already in the menuconfig, is OK.
Offline
Did I say anything wrong??? All I meant to do was give some clarification .
Last edited by B (2007-06-14 05:03:03)
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
Do NOT EVER adjust or use custom cflags on a kernel beyond those available in the kernel config.
It WILL result in a broken kernel, and possibly hardware damage or data loss.
Any config option already in the menuconfig, is OK.
Thanks for the heads up, does this hold true only for kernel compilation? Do you have any references I could take a look at explaining why this is an issue?
I modified the cflags (-march=prescott -O2 -pipe -fomit-frame-pointer) and makeflags (-j3) as per gentoo's safe cflag wiki page in makepkg.conf, but I don't think they took hold as I had to edit my kernel pkgbuild to supply -j3 to make. Will recompile just to be safe though.
cheers,
Last edited by somedrew (2007-06-14 05:50:22)
Offline
now with gcc42 (or is it 4.3?) you just have to use -march=native -mtune=native and gcc will autodetect the best for you.
kernel build system does not use cflags var, for the very reasons mentioned by iphitus: my comment about -march value was just to deduce and highlight that setting the thing to p-m in kernel may not be the optimal choice, though I don't know if p4 is any better.
To know recursion, you must first know recursion.
Offline