Bug 30972 - RH 7.0.9x is not installable on the new Cyrix III processor
Summary: RH 7.0.9x is not installable on the new Cyrix III processor
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-07 18:23 UTC by Alan Cox
Modified: 2007-04-18 16:32 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-03-12 23:33:22 UTC
Embargoed:


Attachments (Terms of Use)

Description Alan Cox 2001-03-07 18:23:08 UTC
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.

Comment 1 Jeremy Katz 2001-03-07 19:44:02 UTC
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).


Comment 2 David Lawrence 2001-03-07 20:04:31 UTC
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.

Comment 3 David Lawrence 2001-03-07 20:14:28 UTC
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.

Comment 4 Glen Foster 2001-03-07 22:06:15 UTC
This defect is considered MUST-FIX (show-stopper) for Florence GOLD

Comment 5 Alan Cox 2001-03-07 22:30:00 UTC
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


Comment 6 Matt Wilson 2001-03-09 15:38:36 UTC
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.


Comment 7 Cristian Gafton 2001-03-12 22:16:18 UTC
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.


Comment 8 Alan Cox 2001-03-12 22:19:19 UTC
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



Comment 9 Preston Brown 2001-03-12 22:20:15 UTC
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.


Comment 10 Matt Wilson 2001-03-12 22:22:14 UTC
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....


Comment 11 Alan Cox 2001-03-12 22:35:11 UTC
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


Comment 12 Cristian Gafton 2001-03-12 23:06:04 UTC
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.


Comment 13 Alan Cox 2001-03-12 23:08:50 UTC
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.


Comment 14 Matt Wilson 2001-03-12 23:10:03 UTC
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.


Comment 15 Cristian Gafton 2001-03-12 23:30:19 UTC
So, what do we loose by calling this Cyrix processor an i586 instead?


Comment 16 Alan Cox 2001-03-12 23:33:17 UTC
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.


Comment 17 Jeff Johnson 2001-03-13 13:27:17 UTC
Added to rpm-4.0.2-7x.


Note You need to log in before you can comment on or make changes to this bug.