Re: Which CPUTYPE for a dualcore Xeon on AMD64
On Mon, Jun 25, 2007 at 08:40:12AM +0300, Abdullah Ibn Hamad Al-Marri wrote: On 6/25/07, Martin Turgeon [EMAIL PROTECTED] wrote: Hi, I recently installed AMD64 6.2 Release on 2 PowerEdge servers, both with dual core Xeon (3070 and 5110). I noticed when I was updating the sources that it was compiling as an Athlonxp by default. I was wondering if I should change the CPUTYPE in make.conf to something else. I read at some places that it is not recommended because it could cause problems but I thought it would be interesting to start the debate here. Please note that I would prefer not to go with the -STABLE or -CURRENT branch because these a going to be essential productions servers. Thank you for your opinions, Martin Since I use FreeBSD 7.0 AMD64 which is stable now and it's frozen for making RELENG_7 I didn't set the CPUTYPE in the make.conf , so I wonder how come you got athlon-xp cpu arch and I didn't see GCC 4.2 doing it in my server. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ Used when compiling lib32 shim libraries, I guess. Yuri pgpv9XfHxj7GP.pgp Description: PGP signature
end, edata, etext issues
Hello,
I'm playing with FreeBSD on ARM. I noticed that sbrk(2) doesn't work
properly on this architecture. I still don't understand the whole process
of the initialisation of end, edata and etext. There are some oddities
that confuse me even more. Let me make an example:
1 #include stdio.h
2 extern end;
3 extern edata;
4 int main() {
5 printf(edata: %08x\n, edata);
6 printf(end: %08x\n, end);
7 printf(sbrk(0): %08x\n, sbrk(0));
8 return (0);
9 }
cc test.c ./a.out
edata:
end:
sbrk(0):
This is obviously not correct and the reason why program that rely sbrk(2)
are broken. I added the following code:
1 .data
2 .globl curbrk
3 curbrk:
4 .word end
and compiled the whole thing again:
cc test.c curbrk.S ./a.out
edata:
end: 0001070c
sbrk(0): 0010
and it seems to work.
Another strange thing is that if I don't access edata, e.g. leave
printf(edata: %08x\n, edata); away, then sbrk still works, but end
is zero. In case I don't access edata or end at all I'll get a bus
error.
Is there somebody who can tell me how end depends on the presence curbrk
and edata in this example?
Regards
Björn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which CPUTYPE for a dualcore Xeon on AMD64
On 6/24/07, Martin Turgeon [EMAIL PROTECTED] wrote: Hi, I recently installed AMD64 6.2 Release on 2 PowerEdge servers, both with dual core Xeon (3070 and 5110). I noticed when I was updating the sources that it was compiling as an Athlonxp by default. I was wondering if I should change the CPUTYPE in make.conf to something else. I read at some places that it is not recommended because it could cause problems but I thought it would be interesting to start the debate here. Please note that I would prefer not to go with the -STABLE or -CURRENT branch because these a going to be essential productions servers. Thank you for your opinions, Martin I use nocona. That should be the correct one. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
KSE was Re: open/close/ioctl api change?
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
found the problem, 'option KSE' which is defined now in DEFAULTS,
and i'm compiling a module! which does not include DEFAULTS!
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
open/close/ioctl api change?
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libelf question
Angus Barrow [EMAIL PROTECTED] writes: 30 time_t timet=arh-ar_date; (gdb) n 31 strftime(timestring, sizeof(timestring), %b %e %H:%M %Y, gmtime(timet)); (gdb) n ... (gdb) print timet $1 = -1515870811 (gdb) p/x -1515870811 $1 = 0xa5a5a5a5 from malloc(3): J Each byte of new memory allocated by malloc(), realloc() or reallocf() will be initialized to 0xa5. All memory returned by free(), realloc() or reallocf() will be initialized to 0x5a. This is intended for debugging and will impact performance nega- tively. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE was Re: open/close/ioctl api change?
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
found the problem, 'option KSE' which is defined now in DEFAULTS,
and i'm compiling a module! which does not include DEFAULTS!
even so it shouldnt' happen..
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
Jack L. wrote: On 6/24/07, Martin Turgeon [EMAIL PROTECTED] wrote: Hi, I recently installed AMD64 6.2 Release on 2 PowerEdge servers, both with dual core Xeon (3070 and 5110). I noticed when I was updating the sources that it was compiling as an Athlonxp by default. I was wondering if I should change the CPUTYPE in make.conf to something else. I read at some places that it is not recommended because it could cause problems but I thought it would be interesting to start the debate here. Please note that I would prefer not to go with the -STABLE or -CURRENT branch because these a going to be essential productions servers. Thank you for your opinions, Martin I use nocona. That should be the correct one. I know I am hijacking the thread a bit - but: In general, how does one decide which CPUTYPE to use? The connection between the options for CPUTYPE and the output of dmesg is not so obvious to me. I looked at the features advertised by dmesg (which in my case included SSE3) and then reverse engineered bsd.cpu.mk to figure out I should be using prescott, but I am hoping I figured it out the hard way. Also, does setting CPUTYPE make a lot of difference to performance? Right now I have no CPUTYPE set at all. Thanks, Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
On Mon, Jun 25, 2007 at 12:45:37PM -0500, Stephen Montgomery-Smith wrote: Also, does setting CPUTYPE make a lot of difference to performance? I don't notice any difference in performance on my Athlon xp 2400 box if I set CPUTYPE=athlon-xp vs. leaving it alone. YMMV though, ask the gentoo people :) Right now I have no CPUTYPE set at all. Also leaving CPUTYPE unset means I can plug the system disc into any other old x86 box without hitting illegal instructions. In case my motherboard fries itself again some time like the old one did a few weeks ago I'll be glad I can do this. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpJ6Nazagig5.pgp Description: PGP signature
Re: KSE was Re: open/close/ioctl api change?
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under
current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
found the problem, 'option KSE' which is defined now in DEFAULTS,
and i'm compiling a module! which does not include DEFAULTS!
even so it shouldnt' happen..
why? I'm compiling outside the source tree.
I agree that it shouldn't, specially, since it took me a long
time to find the problem :-), but I can't see how config options
can be exported. Unless, the make file is made aware of the KERNCONF file.
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE was Re: open/close/ioctl api change?
Danny Braniss wrote:
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
found the problem, 'option KSE' which is defined now in DEFAULTS,
and i'm compiling a module! which does not include DEFAULTS!
even so it shouldnt' happen..
why? I'm compiling outside the source tree.
I agree that it shouldn't, specially, since it took me a long
time to find the problem :-), but I can't see how config options
can be exported. Unless, the make file is made aware of the KERNCONF file.
there should be no place in the source at any time where a thread
that is not on the free list could have a td_proc of NULL.
it doesn't matter about where a module came from etc.. the fact that
it happened is a bug somewhere.
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
In general, how does one decide which CPUTYPE to use? The connection between the options for CPUTYPE and the output of dmesg is not so obvious to me. I looked at the features advertised by dmesg (which in my case included SSE3) and then reverse engineered bsd.cpu.mk to figure out I should be using prescott, but I am hoping I figured it out the I would not judge only by instructions like SSE etc. ins scheduling etc. plays key role as well. you should know what cpu you bought, or just use cpuid (found in ports) and determine what cpu you have. on -current you can set _native_ or native (dont remember) and gcc will choose itself... ;) roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE was Re: open/close/ioctl api change?
Danny Braniss wrote:
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under
current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, td-td_proc=%p, td-td_proc);
debug(3, td-td_proc-p_pid=%d pid=%d,
td-td_proc-p_pid, curproc-p_pid);
...
the first debug prints out td-td_proc=0 and the next one panics.
found the problem, 'option KSE' which is defined now in DEFAULTS,
and i'm compiling a module! which does not include DEFAULTS!
even so it shouldnt' happen..
why? I'm compiling outside the source tree.
I agree that it shouldn't, specially, since it took me a long
time to find the problem :-), but I can't see how config options
can be exported. Unless, the make file is made aware of the KERNCONF file.
there should be no place in the source at any time where a thread
that is not on the free list could have a td_proc of NULL.
it doesn't matter about where a module came from etc.. the fact that
it happened is a bug somewhere.
Julian,
I compiled the kernel, and DEFAULT contains
option KSE
then I compiled the loadable module, outside the source tree, where
KSE is not defined, the thread structure has #ifdef KSE ... #endif
so my module sees a different thread structure. The real arguable issue
is that the #ifdef KSE is below the *td_proc, So td-proc should not
be affected by the ifdef. BTW, it was NULL when compiled for i386,
garbage for amd64.
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: you should know what cpu you bought, or just use cpuid (found in ports) and determine what cpu you have. Knowing what CPU you bought doesn't help a lot for the case asked about of nocona vs. prescott. Those are the names of P4 and Xeon cores, not CPUs - and not the last cores used in either line. cpuid will tell you what features your CPU supports, but not the name of the core. So it only helps if you know what you're looking for. P4 and Xeon are just marketing names, and the features available vary quite a bit across the lines. Even knowing the core names doesn't help, as some prescott cored P4s have all the gcc nocona features. Assuming the gcc man page is correct, use cpuid to check the feature sets of your CPU. If you don't have SSE2, then you should be using something prior to pentium 4. If you have SSE2 but not SSE3, then you want pentium-m, pentium4 or pentium4m. If you have SSE3, then you should be using either nocona or prescott. If you have 64 bit support, you want nocona, otherwise prescott. For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
Mike Meyer a écrit : In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: you should know what cpu you bought, or just use cpuid (found in ports) and determine what cpu you have. Knowing what CPU you bought doesn't help a lot for the case asked about of nocona vs. prescott. Those are the names of P4 and Xeon cores, not CPUs - and not the last cores used in either line. cpuid will tell you what features your CPU supports, but not the name of the core. So it only helps if you know what you're looking for. P4 and Xeon are just marketing names, and the features available vary quite a bit across the lines. Even knowing the core names doesn't help, as some prescott cored P4s have all the gcc nocona features. Assuming the gcc man page is correct, use cpuid to check the feature sets of your CPU. If you don't have SSE2, then you should be using something prior to pentium 4. If you have SSE2 but not SSE3, then you want pentium-m, pentium4 or pentium4m. If you have SSE3, then you should be using either nocona or prescott. If you have 64 bit support, you want nocona, otherwise prescott. For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo mike Thanks a lot for the precision, I will use nocona for my dual core Xeon. Martin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
Martin Turgeon wrote: Mike Meyer a écrit : In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: you should know what cpu you bought, or just use cpuid (found in ports) and determine what cpu you have. Knowing what CPU you bought doesn't help a lot for the case asked about of nocona vs. prescott. Those are the names of P4 and Xeon cores, not CPUs - and not the last cores used in either line. cpuid will tell you what features your CPU supports, but not the name of the core. So it only helps if you know what you're looking for. P4 and Xeon are just marketing names, and the features available vary quite a bit across the lines. Even knowing the core names doesn't help, as some prescott cored P4s have all the gcc nocona features. Assuming the gcc man page is correct, use cpuid to check the feature sets of your CPU. If you don't have SSE2, then you should be using something prior to pentium 4. If you have SSE2 but not SSE3, then you want pentium-m, pentium4 or pentium4m. If you have SSE3, then you should be using either nocona or prescott. If you have 64 bit support, you want nocona, otherwise prescott. For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo mike Thanks a lot for the precision, I will use nocona for my dual core Xeon. Martin Sorry for not having a reference but it came from an Intel internal site. Here are the highlights for some of the past players: Cedar Mill: Last P4 processor. Followup to Prescott. Conroe: Desktop version of the Core2Duo processor. Mobile equivalent is Merom. Dothan: 2nd gen. Pentium M CPU. Nocona: Xeon server processor code name -- first CPU with EMT64 (amd64) compatibility [and hence first non-IA64 bit Xeon processor to feature 64-bit compatibility; not sure if it was the first non-IA64 64-bit designed Intel processor]. Prescott: Single-core processor with HTT. Base CPU for [later generation] P4 processors, and the dual core Pentium D [basically the larger cousin of the Northwood CPUs]. Prescott was compacted into Cedar Mill -- from a 90nm (?) process to 65nm. Sossaman: Dual-core Xeon processor, based off of Yonah. Woodcrest: Server version of Conroe/Merom. Yonah: First Duo/Solo processor. Based off of Dothan. Some people have claimed that pentium-m is better for Core * based processors because of the shorter pipelines and lower frequency (found via a google discussion about gcc and -march, but I can't be sure of its validity), but pentium-m is a 32-bit CPU, thus it's not an option for 64-bit computing. Intel suggests using -march=prescott (32-bit) and -march=nocona (64-bit) with gcc on Core2Duo processors and equivalent Xeons. You can also find your CPU's type by going to this page: http://www.intel.com/products/server/processors/index.htm?iid=serv_body+proc, and searching for the appropriate model number. Your frequency and model should be reported in your BIOS, if not the first couple lines of dmesg in FreeBSD. Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
In [EMAIL PROTECTED], Garrett Cooper [EMAIL PROTECTED] typed: Martin Turgeon wrote: Mike Meyer a écrit : In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo Thanks a lot for the precision, I will use nocona for my dual core Xeon. Cedar Mill: Last P4 processor. Followup to Prescott. Nocona: Xeon server processor code name -- first CPU with EMT64 (amd64) compatibility [and hence first non-IA64 bit Xeon processor to feature 64-bit compatibility; not sure if it was the first non-IA64 64-bit designed Intel processor]. Prescott: Single-core processor with HTT. Base CPU for [later generation] P4 processors, and the dual core Pentium D [basically the larger cousin of the Northwood CPUs]. Prescott was compacted into Cedar Mill -- from a 90nm (?) process to 65nm. From what I can tell, the Prescott went through a number of iterations; the first of them didn't have HTT, or had it but it was disabled. Later versions added that, EMT64, virtualization, and other things. If my information is correct, the nocona was the first version of the prescott core with em64t, and only used in Xeons. And yes, I believe prescott and following were 90nm until Cedar Mill. Intel suggests using -march=prescott (32-bit) and -march=nocona (64-bit) with gcc on Core2Duo processors and equivalent Xeons. Note that /usr/share/mk/sys.mk includes bsd.mk.cpu, which overrides CPUTYPE if it's set to prescott or nocona. It turns nocona into prescott if you're building for i386 and prescott into nocona if you're building for amd64. So the correct answer to the question Do I set CPUTYPE to nocona or prescott in /etc/make.conf? would seem to be It doesn't matter. You can also find your CPU's type by going to this page: http://www.intel.com/products/server/processors/index.htm?iid=serv_body+proc, and searching for the appropriate model number. Your frequency and model should be reported in your BIOS, if not the first couple lines of dmesg in FreeBSD. I've never seen those report core names. Possibly you're referring specifically to the Xeon cpu model numbers? thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
