DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD General

FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 5th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default FreeBSD amd64 arch Cpu type

Hello

I couldn't help but learn that people from the bsdforums are moving here, so I'll re-post my question.

I have an Intel Core 2 Quad Q6600 CPU and was wondering if there was a better cpu type than "Hammer" to use for this processor? Is it even possible to choose others for this arch? I figured that was probably the best target, (hence, the default for amd64), and it seems to detect my CPU's features correctly but is there something I could choose that's more optimal? I configured and built my kernel and it seems to run just fine but there's always that nagging doubt that I could have used something better

The NOTES only shows HAMMER

I thought I'd look through some of the cpu related stuff under /usr/src/sys/amd64 and found this. (cputypes.h)

Code:
/*
 * Classes of processor.
 */
#define	CPUCLASS_X86	0	/* X86 */
#define	CPUCLASS_K8	1	/* K8 AMD64 class */
/*

 * Kinds of processor.
 */
#define	CPU_X86		0	/* Intel */
#define	CPU_CLAWHAMMER	1	/* AMD Clawhammer */
#define	CPU_SLEDGEHAMMER 2	/* AMD Sledgehammer */
Would I be better off defining X86 instead (and still obviously have a 64 bit kernel)

This is what I get from dmesg (looks ok to me... detected as a K8-class)

Code:
CPU: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz (2400.01-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11
  Features=0xbfebfbff<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,HTT,TM,PBE>
  Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 4
Reply With Quote
  #2   (View Single Post)  
Old 5th May 2008
FloridaBSD FloridaBSD is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 58
Default

The Intel Core two Duo processors are considered as members of the x86_64 processor family, which fiI am not the least bit wrong means that the iso images you used to burn your installation media wern't he correct ones.
__________________
Google Linux is a Green Horns Best Friend (GHBF).
Windows = a 32 bit extensions to a 16 bit patch to an 8 bit operating system originally coded for a four bit processor written by 2-bit monopolistic software company founded by a .3-bit Harvard Drop out, who can't stand one respectable bit of competition.
If I believe something to be immoral a will not keep quite and let my voice of annoyance be heard loud and clear.
Reply With Quote
  #3   (View Single Post)  
Old 5th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Thanks for the reply, but that's not true. "amd64" refers to the arch and is generally synonymous with x86_64 (in fact x86_64 is the arch according to the compiler) The other 64 bit download option, ia64, is a completely different arch for Itanium-like processors. That would definitely not run.
Reply With Quote
  #4   (View Single Post)  
Old 5th May 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Quote:
Originally Posted by Grogan View Post
I have an Intel Core 2 Quad Q6600 CPU and was wondering if there was a better cpu type than "Hammer" to use for this processor?
AMD released their 64-bit CPU extensions first, and were the first supported by FreeBSD. Hence, the FreeBSD port to 64-bit x86 is called "amd64" and the CPU class in the kernel is called "HAMMER". AMD's Hammer class of CPUs were the first ones to support 64-bit (Sledgehammer, Clawhammer, and one other hammer).

Hence, in the kernel config, the correct cpu entry to use is HAMMER, for all 64-bit x86 CPUs.

Quote:
Is it even possible to choose others for this arch?
No.

Quote:
I configured and built my kernel and it seems to run just fine but there's always that nagging doubt that I could have used something better
Well, you could have used a real amd64 CPU from AMD.

Quote:
This is what I get from dmesg (looks ok to me... detected as a K8-class)
K8 was the name given to the Hammer family of CPUs by AMD. It followed the K7. Just as every Intel CPU since the PentiumPro has been an "i686-class" CPU, so has every CPU from AMD since the Athlon64 been a "K8-class" CPU. Intel and AMD CPUs running in 64-bit mode are considered "K8-class" while Intel and AMD CPUs running in 32-bit mode are considered "i686-class".
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
  #5   (View Single Post)  
Old 5th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Thanks, that confirms much of what I thought. I just didn't know for sure if there were other CPU types available. (Note that I'm coming from Linux where there are individual definitions for various processors. It's still much the same though, the kernel will still detect the CPU's features properly and will still run on a compatible one, though perhaps not optimally)

This is a Hell of a nice setup.
Reply With Quote
  #6   (View Single Post)  
Old 5th May 2008
FloridaBSD FloridaBSD is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 58
Question

Does this mean that the AMD Atlon X2 Duel Core 5600+ processor in my Pavillion a6230n Desktop Is acyurally not based uopon a true sixty-four bit Processor, but instead A 32 bit chip masquerading as a 6bit chip
__________________
Google Linux is a Green Horns Best Friend (GHBF).
Windows = a 32 bit extensions to a 16 bit patch to an 8 bit operating system originally coded for a four bit processor written by 2-bit monopolistic software company founded by a .3-bit Harvard Drop out, who can't stand one respectable bit of competition.
If I believe something to be immoral a will not keep quite and let my voice of annoyance be heard loud and clear.

Last edited by FloridaBSD; 26th May 2008 at 04:53 AM.
Reply With Quote
  #7   (View Single Post)  
Old 5th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Essentially correct, the x86_64 chips (AMD64 and later copied by Intel who calls it EM64T) are really x86 processors with 64 bit extensions (additional registers and stuff activated by a 64 bit operating system kernel). They can run both 32 bit and 64 bit code natively. That doesn't mean anything inferior... it's the best of both worlds. Intel's idea of IA64 didn't really catch on, it was too incompatible. Microsoft thumbed their noses at it because too much of their rubbish would have had to be rewritten from the ground up lol
Reply With Quote
  #8   (View Single Post)  
Old 5th May 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Quote:
Originally Posted by Grogan View Post
Thanks, that confirms much of what I thought. I just didn't know for sure if there were other CPU types available. (Note that I'm coming from Linux where there are individual definitions for various processors.
The Kernel CPU type is for the architecture of the machine (i386, hammer, ia64, ppc, etc). This is the broad, general architecture (instruction set) of the system. Internally, the individual source files will check for various functions of the underlying hardware and use what's best. FreeBSD tries to keep things simple, in that it gives you classes of features/drivers to enable, and then auto-detects the specifics as needed (compare ATA subsystems - FreeBSD: device ata vs. Linux: several pages of individual chipsets to select from)

You can set the exact CPU type in the machine via /etc/make.conf and that will enable different features in the software you install via the ports tree or when compiling the world or kernel. See /usr/share/examples/etc/make.conf for all the details. This sets all the gcc options like -m -cpu and so forth.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
  #9   (View Single Post)  
Old 5th May 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Quote:
Originally Posted by FloridaBSD View Post
Does this mean rthat the AMD Atlon X2 Duel Core 5600+ processor in my Pavillion a6230n Desktop Is acyurally not based uopon a true sixty-four bit Processor, but instead A 32 bit chip masquerading as a 6bit chip
64-bit x86 CPUs are not "designed from the ground up" to be 16-bit, 32-bit, or 64-bit (the 80286 was just a 16-bit evolution of the 8-bit 8086, the 80386 was just a 32-bit evolution of the 16-bit 80286, and the athlon64 is just a 64-bit evolution of the 32-bit 80386). They are just extensions of earlier designs to support new 64-bit features. They are an evolutionary step in the lifetime of the x86 architecture. However, that's not to say they aren't true 64-bit CPUs, as they are; it just depends on the OS you install.

If you install a 32-bit OS on your amd64 CPU, you get a souped-up 32-bit CPU.

If you install a 64-bit OS on your amd64 CPU, you get a 64-bit CPU, with all the advanced features that come with it.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 5th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Quote:
Originally Posted by fjwcash View Post
You can set the exact CPU type in the machine via /etc/make.conf and that will enable different features in the software you install via the ports tree or when compiling the world or kernel. See /usr/share/examples/etc/make.conf for all the details. This sets all the gcc options like -m -cpu and so forth.
I do this in make.conf:

For kernel:
COPTFLAGS=-O2 -march=nocona

That's safe enough, because the kernel build system turns off potentially harmful instructions (e.g. -mno-sse2 -mno-sse3 -mno-mmx etc.) that would be enabled by -march.

That's just optimizing the execution of the kernel functions themselves though.

For general software:
CFLAGS=-O2 -mtune=nocona

That's safe enough to enable globally. -mtune just tunes the scheduling and stuff for the specified cpu and doesn't break anything.

nocona is about the closest thing to correct that gcc 4.2.x will do for my CPU. Once gcc 4.3.x is a bit more mature and usable (and projects catch up with it), there's a core2 cpu type.
Reply With Quote
Old 6th May 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Don't do that. Leave CFLAGS alone. You have removed a whole list of defaults that may lead to breakage down the line.

Set CPUTYPE in /etc/make.conf and let the make system fill in the rest based on that. CPUTYPE sets -march, -mtune, and a bunch of others.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 6th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Hmm, OK, thanks. I'll stop doing that (Been doing CFLAGS in make.conf since FreeBSD 5 though). I would have thought it just appended to the compile commands. I've never done a build world though, but it's never caused me a problem with any of the ports that I use.

I wouldn't want to do CPUTYPE=nocona though, because that will blindly enable things like SSE2 and SSE3 etc. which does break builds, or worse, subtly breaks the results. CPUTYPE seems to do -march
Reply With Quote
Old 7th May 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

CPUTYPE sets various flags for port and world compiles. It doesn't enable things like SSE for kernel compiles, though. The build system is smart enough to know what is safe for the kernel and what is safe for the world.

Until you set CFLAGS, that is. Then things can go haywire. If you use CFLAGS=whatever, then you are replacing the CFLAGS set in the build system. If you use CFLAGS+=whatever, then you append to the end of the CFLAGS line, again overriding anything set previously. If you use CFLAGS="whatever ${CFLAGS}" then you add your option in front of the defaults, and the defaults override your settings. Things can get pretty hairy.

And the default CFLAGS do change overtime (for instance, -O2 is the default now).

Better to set CPUTYPE, don't set CFLAGS, and just let the build system do its job.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 7th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Yep, I agree there's no problem with using -march for the kernel (as stated, the kernel build system disables such instructions with with -mno in every compile command, including the modules that get built for everything you disable in the main kernel image) but that's not the case with ports.

In my sillier days, I used to do -march=pentium4 for everything I compiled in Linux until I learned that SSE2 subtly breaks stuff. It's not something you can put your finger on either. One time I had a problem with certain gtk+ dialogs intermitently crashing the X server. Some chooser dialogs, Gimp options, the file manager in XFCE. The cause was GTK+ being compiled with -march=pentium4, specifically the use of SSE2. That caused me a lot of aggravation. I was attacking the problem as if it was something to do with X. As if it was something to do with the Radeon driver. Everything but Grogan and his stupid compile flags :-)

I've also subtly broken some functions in programs that way too. The rest of the program works fine, except for a few features.

That said, I decided to do it anyway lol

CPUTYPE=nocona in make.conf. If anything breaks, I'll fix it and not do it anymore. I just want to see for myself how things have progressed. Things may not miscompile anymore, gcc is smarter than it used to be now too.

I took out the other stuff.

I wanted to rebuild my kernel again tonight anyways, to try that SCHED_ULE which is purported to be a better scheduler for SMP. So far it's doing quite well (watching top while the system is under stress) and staying snappy.

Last edited by Grogan; 7th May 2008 at 06:55 AM.
Reply With Quote
Old 9th May 2008
pcfxer pcfxer is offline
Port Guard
 
Join Date: May 2008
Location: Ottawa, Ontario, Canada
Posts: 14
Default

Quote:
Originally Posted by Grogan View Post
Essentially correct, the x86_64 chips (AMD64 and later copied by Intel who calls it EM64T) are really x86 processors with 64 bit extensions (additional registers and stuff activated by a 64 bit operating system kernel). They can run both 32 bit and 64 bit code natively. That doesn't mean anything inferior... it's the best of both worlds. Intel's idea of IA64 didn't really catch on, it was too incompatible. Microsoft thumbed their noses at it because too much of their rubbish would have had to be rewritten from the ground up lol
...and then made efficient and secure-WHAT A CONCEPT!>!>!

GROGAN I have only broken ports when using the -jx option. My system has never run better since specifying CPUTYPE in make.conf
Reply With Quote
Old 9th May 2008
DrJ DrJ is offline
ISO Quartermaster
 
Join Date: Apr 2008
Location: Gold Country, CA
Posts: 507
Default

Quote:
Originally Posted by pcfxer View Post
GROGAN I have only broken ports when using the -jx option.
-jx works fine for building world, but not for the kernel or ports. Making ports suitable for parallel compilation is happening, but is not there yet.
Reply With Quote
Old 9th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Thanks guys, coincidently I just did a buildworld tonight, with CPUTYPE=nocona and it passed -march in the compile commands. So far, everything seems to be good.

First time I did one and it wasn't a big job at all. It didn't even take an hour, even without -j. (I chickened out on that because it said to avoid using it in the notes). Next time I'll try -j5.

It'll be good if they ever make ports parallel build safe... it's a drag when you're waiting on stuff to finish. (though there's nothing stopping me from doing other non-ports build jobs at the same time)
Reply With Quote
Old 10th May 2008
Grogan's Avatar
Grogan Grogan is offline
Port Guard
 
Join Date: May 2008
Location: Ontario, Canada
Posts: 23
Default

Well, even though ports doesn't support -j, there's nothing stopping me from getting work done. I've been redoing KDE from ports tonight, and after I got libs and base and stuff down, I've been building 3 ports at the same time to get all the rest of the KDE components done. And still plenty of CPU cycles free for surfing the web and listening to tunes and stuff at the same time :-)

I was worried that maybe some environment variables would collide or something, but since they are separate virtual terminals (rxvt) that can't really happen.

Really good scheduling here... I can hardly tell I'm compiling. I think this is where FreeBSD kicks ass.
Reply With Quote
Old 26th May 2008
Calderon's Avatar
Calderon Calderon is offline
Real Name: Patrick Lindholm
Fdisk Soldier
 
Join Date: May 2008
Location: Finland
Posts: 60
Default

Can i use CPUTYPE Athlon or Athlon-xp, as i´m having duron 1800Mhz applebred?

Some say that the only difference between athlon and that duron is cache...

If i can´t, what should i use?

Thanks.

http://www.cpu-world.com/CPUs/K7/AMD...1800DLV1C.html
Reply With Quote
Old 26th May 2008
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Default

I think that the only CPUTYPE for amd64 at the moment is athlon64.

OH, and please don't threadjack. If you have a question, ask it with a new thread (after searching, of course). Please do not simply tack it onto the end of someone else's thread.

Doubly important if the thread does not apply to your CPU - that is not a 64 bit cpu!!!

A slightly older /usr/share/examples/etc/make.conf lists these as the CPUTYPES for AMD CPUs
Code:
#       (AMD CPUs)      opteron athlon64 athlon-mp athlon-xp athlon-4
#                       athlon-tbird athlon k8 k6-3 k6-2 k6 k5
Take your pick.
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
FreeBSD 7.2 amd64 no sound erim FreeBSD General 5 3rd June 2009 07:54 AM
strange load problem on freebsd 7.0 amd64 skynet_tech FreeBSD General 3 11th September 2008 09:49 PM
Wine on FreeBSD 7.0 amd64 BlueJayofEvil FreeBSD Ports and Packages 13 29th July 2008 12:22 AM
jdk16 plugins on FreeBSD 7 AMD64 ninjatux FreeBSD General 0 26th June 2008 07:55 PM
FreeBSD 7.0 amd64 make installworld fails. KernelPanic FreeBSD Installation and Upgrading 8 11th June 2008 04:34 PM


All times are GMT. The time now is 10:46 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick