Hide Forgot
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 this again.
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 below. 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. So either: 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 use. 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 answer. 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 this target.
Added to rpm-4.0.2-7x.