Why is the athlon optimised compiled kernel available in Fedora? Also if I try to rebuild from SRPM, it tells me that athlon architecture is not included.
Thanks VJ
VJ wrote:
Why is the athlon optimised compiled kernel available in Fedora? Also if I try to rebuild from SRPM, it tells me that athlon architecture is not included.
There is no Athlon specific kernel in FC2 because one is not needed. The 2.6 kernel is clever enough to handle any Athlon specific optimisations on the fly rather than having to have them compiled in. Just use the i686 kernel instead.
Simon.
Cheers Simon.
----- Original Message ----- From: "Simon Andrews" simon.andrews@bbsrc.ac.uk To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Tuesday, July 27, 2004 1:57 PM Subject: Re: Why there is no athlon specific kernel in Fedora core 1/2 ?
VJ wrote:
Why is the athlon optimised compiled kernel available in Fedora? Also if
I
try to rebuild from SRPM, it tells me that athlon architecture is not included.
There is no Athlon specific kernel in FC2 because one is not needed. The 2.6 kernel is clever enough to handle any Athlon specific optimisations on the fly rather than having to have them compiled in. Just use the i686 kernel instead.
Simon.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
Hi,
Why is the athlon optimised compiled kernel available in Fedora? Also if I try to rebuild from SRPM, it tells me that athlon architecture is not included.
Certainly from the 2.6 kernel there wasn't an Athlon option - mainly as the kernel now self detects the processor and applies the optimisations itself. You just have to use the i686 version to access this.
TTFN
Paul
On Tue, 2004-07-27 at 14:25 +0100, Paul wrote:
Hi,
Why is the athlon optimised compiled kernel available in Fedora? Also if I try to rebuild from SRPM, it tells me that athlon architecture is not included.
Certainly from the 2.6 kernel there wasn't an Athlon option - mainly as the kernel now self detects the processor and applies the optimisations itself. You just have to use the i686 version to access this.
There certainly IS an option in 2.6 for Athlon- it is CONFIG_MK7, in the kernel config menu it is under "Processor type and features --> Processor Family" (with Subarchitecture type set to "PC-compatible").
Note: I've been using the kernel-source rpm to build custom kernels, rather than trying to use the kernel SRPM (I also am not yet up to the latest FC2 kernel on my laptop), so I can't say what the issue is with the original poster, but I suspect he'll need to update the spec file as well as the kernel config used in the SRPM.
On Tue, 2004-07-27 at 14:25 +0100, Paul wrote:
Certainly from the 2.6 kernel there wasn't an Athlon option - mainly as the kernel now self detects the processor and applies the optimisations itself. You just have to use the i686 version to access this.
Actually I thought what they did was to alter some of the makefiles so that depending on what target CPU you selected from the config options the makefiles would set the correct optimization flags for that target, negating the need for you to pass which CPU from the family you were using in order to get the correct optimizations. Makes sense really, in that you've already stated it in the config file what CPU its going to be for.
Would appreciate someone clearing that bit up though, as I can't find a definitive explaination on this, i.e. as to whether it definitely works backed up with links to approiate articles explaining how it works. Kernel docs don't seem to be providing anything about this either, unless I'm stareing at the wrong files.
Not that I'm dismissing the possiblity, I'm quite interested in the idea, but since searching with google hasn't turned up anying good on this, and I can't find anything deffitive on this, I am uncertain as to what exactly the kernel is doing when it encounters different CPU architectures and how well it can optimize for the different CPU's
Any further details or a good link on that particular subject would be appreciated (or even better search terms for google :) )
In any case I was feeling pedantic about being able to specify athlon and have a separate athlon config so I went about modifying the spec file and generating a new config file. Besides, I wanted to be able to strip out a lot of the extra drivers, etc, and add in a few things that are missing.
There certainly IS an option in 2.6 for Athlon- it is CONFIG_MK7, in the kernel config menu it is under "Processor type and features --> Processor Family" (with Subarchitecture type set to "PC-compatible").
Note: I've been using the kernel-source rpm to build custom kernels, rather than trying to use the kernel SRPM (I also am not yet up to the latest FC2 kernel on my laptop), so I can't say what the issue is with the original poster, but I suspect he'll need to update the spec file as well as the kernel config used in the SRPM.
Yeah, there's a couple of problems with the spec file that you need to sort if you want to be able to specifiy athlon as a target.
I've attached (normally I'd just still it up in my webspace and post the url here but the webspace is currently out of action at the moment, so apologies if people don't appreciate the attachments. I've bzip'ed them to make them as small as possible.) my own version of the spec file + config file which should work just fine, its basically just the i686 config file changed for the athlon using the config menu's and saved. Then run using the "make ARCH=i386 nonint_oldconfig" to make sure it wouldn't have any issues when that is performed silently. Just remember I haven't used that particular config file, as I normally edit it further to strip out all the unnessary items not required for my system and add in some of the extras that I want, such as nfts read support.
steps in general install SRPM unpack resulting tarball from /usr/src/redhat/SOURCES to /usr/src/redhat/BUILD apply all the patches go to /usr/src/redhat/BUILD/kernel-2.6.6/linux-2.6.6/ (might be slightly different names) make oldconfig make gconfig or make xconfig, etc save the config file make ARCH=i386 nonint_oldconfig (this is where issues with the config file will cause a crap out, running it twice might solve your problem, but if it doesn't pass this, you won't be able to create a new rpm using it.) Once you have a config file that can pass this step then you can add it to the rest of the sources, I renamed mine to kernel-2.6.6-athlon.config and copied it to a safe location as well as /usr/src/redhat/SOURCES
modify the the kernel-2.6.6.spec file under /usr/src/redhat/SPECS to add the entries to be able to use the new config file as well as handle being passed the target athlon. You could of course just copy your new config file over one of the existing ones in the SOURCES directory and set the target option so that it will use that one.
You can simply use my provided config file and spec file and copy them into the source folder and spec folder respectively after installing the SRPM and issue the command from /usr/src/redhat/ rpmbuild -bs SPEC/kernel-2.6.spec
which will generate a new SRPM that you can use to build the binaries from. Just remember that I'm using version 2.6.6-1.435.2.3, so if you go to use the config file with any other version you will need to use the make ARCH=i386 nonint_oldconfig command to take care of any config changes before you attempt to compile a new kernel from it.
Areas that I altered,
# groups of related archs %define all_x86 i586 i686 athlon
added an %ifarch for athlon as well added a line for the source Source37: kernel-%{kversion}-athlon.config
Also modified the following line make ARCH=`echo $i | cut -d"-" -f3 | cut -d"." -f1 | sed -e s/i.86/i386/ -e s/s390x/s390/ -e s/ppc64.series/ppc64/ -e s/ppc8260/ppc/ -e s/athlon/i386/` nonint_oldconfig > /dev/null
Athlon still uses the basic i386 arch folder, its just the CFLAGS passed to the compiler are optimized differently depending on your config file AFAIK.
I suppose I could have left it alone and just copied over my config file over the i686 file, but as I stated earlier I was being a little pedantic. Besides its good to be able to understand what the hell is going on in those spec files.
-
Aaron Gaudio -
Darragh Bailey -
Paul F. Johnson -
Simon Andrews -
VJ