Anders Johansson wrote:
On Monday 22 September 2003 21.14, js wrote:
<snip> so it became worth it since there needed to be a forked kernel anyway. "Lucky" for us Athlon users. (Never thought a bug would do some good)
First of all it's not a fork, since it's maintained in the main kernel tree. Secondly, I just greped the source for athlon specific things, and the only thing I could find different between compiling for athlon and compiling for Pentium III is the use of 3DNow and a different implementation of MMX.
Of course, I may have missed something. I greped for CONFIG_MK7 and I looked at arch/i386/config.in and compared the defines set for the various architectures
Ah, yes. I forgot the term fork has special meaning in the *nix world. Anyway, the Athlon bug disappeared in more recent processors such as those >= Thunderbird. The fork/non fork is just my terminology which I thought would make it more clear since it originally appeared as a patch you had to apply yourself. It was later added to the main branch so that you could select it in the processor type section, so technically you are correct of course. I thought this would make more sense in the context of Steve's question. I wanted to point out that the Athlon bug was the reason the Athlon got separate attention to begin with, once Athlon specific code was added to the tree it just went from there. Since suse doesn't expect each user to compile their own kernel, including those with Athlons, it is only logical that they would have to compile a separate one for Athlon systems since there are still people with Athlon computers which have this bug (like myself--600MHZ slot A). My Pentium and Athlon XP types are unaffected. Besides, optimizing the 3DNOW code is great for games and the gimp. J