We erroneously install .i686.rpm packages on all model 6 processsors. This
is wrong because our packages and gcc unconditionally use cmov which is not
an always present model 6 instruction. We must check that cmov is in the
CPUID data as well as the CPU model.
These processors are drop in replacements for the intel celerons at lower
performance but under half the price, so we can expect to see plenty of
them in upcoming bottom end systems.
Anaconda just uses the architecture handling of RPM iirc... and RPM justs bases
off of what it was told for and then tells gcc what to do. If all i686 arches
don't have cmov, then gcc probably shouldn't use it when invoked with
-march=i686 (at least IMO).
Verified that the boot problem also happens on a Cyrix MII socket 7 processor. I
have been told that the latest kernel build fixes this issue. I will need to try
kernel-2.4.2-0.1.22.i686.rpm seems to fix this problem at least for the Cyrix
MII. Please try this
from rawhide when it shows up.
This defect is considered MUST-FIX (show-stopper) for Florence GOLD
Please dont muddle Cyrix MII and MIII things up. They are unrelated. The Cyrix
III is a winchip derivative and has no technical heritage (even the cpuid vendor
string is different) to the MII.
The Cyrix III reports model 6 and a Centaur ID string. The bug however is
unrelated to any of this and could bite us on any future processor. If the
/proc/cpuinfo flags does not contain the cmov flag we must use i586 packages or
The user space installed is incorrect. Even if you replace the kernel with the
boot one the userspace does not function
if the cpu family reports 6 then we'll need to check the cmov bit in features.
This check will have to go in to RPM. When RPM is fixed to make the Cyrix III
appear to be archcompat with i586.
Please provide code for this test and submit to Jeff.
This is NOt an RPM bug. RPm is using uname() to get the processor type. now if
the kernel is so broken to have different types of i686 reports then tough luck.
I don't see why RPM needs to check the availability of some instruction when the
kernel gets it wrong in the firts place.
Grow up Cristian, and while you are at it read your intel architecture
specification. When you've
finished then take it up with the gcc people.
CMOV is not a _required_ instruction in the i686 specification. Intel too are
free at any moment to drop it from their processors. You are required by Intels
own documentation to check the cpuid cmov flag before using cmov.
a) Fix the compiler
b) Fix the installer
OK, let's stop passing the buck back and forth, and figure out who is going to
deal with this. Maybe picking up the phone might be a good idea.
let me make it clear, though - I use rpm's archsore. That's all I'm going to
I can see how this will break up2date, though....
As far as I can see it there are two options
#1 Fix gcc to generate code according to the documentation from Intel. Thats I
think unwise since
god knows what new bugs we might find in apps triggered by it - QA nightmare
#2 Fix rpm to know that '686' isnt what we meant.
I firmly believe it should be #2, and perhaps for RPM5 we can get architecture
requirements as dependancies/provides as Erik, Larry McVoy and I discussed in
umm 1996 I think
This still doesn't change how artificial this artifact you request feels and
looks like, Alan.
Another option would be to actually do the right thing and get an archname of
something like i686_nocmov that can be scored lower in the architecture
compatibility table that RPM uses.
Hacking rpm to understand that i686 is not compatible with i686 is not the right
rpm understands comatibility maps and those compatibility maps have to be simple
to keep things sane. There are simple rules that build these tables and that
tell rpm what packages can be installed on an i686 processor.
Then go away, fix your compiler bug so your i686 packages actually are i686 and
bug me in a week when you've finished QA'ing. i686 is an architecture where cmov
is optional. Intel say so.
what we're saying here is that the current "architecture" mapping of RPM is
broken. Totally and completely broken. We will have to continue to
band-aid(tm) the problem in RPM, where the ROOT of the problem is, until it is
redesigned. We've painted ourselves into a corner by assuming that all i686
processors have cmov, which is totally false. It is our own fault.
So, what do we loose by calling this Cyrix processor an i586 instead?
If you mean change uname you lose compatibility with the real Linux kernel,
which will report 686, and which if it breaks your apps will be publically made
clear whose fault it is.
If you mean install 586 rpms you actually get pretty much what you want except
for prefetch and MMX optimisations which we are not doing right now. As far as I
can measure performance wise 586 is a perfectly sane gcc -m option to use for
Added to rpm-4.0.2-7x.