Bug 145266

Summary: ia32e kernel returns x86_64 in uname
Product: Red Hat Enterprise Linux 3 Reporter: Oren Gimel <oren>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: barryn, jparadis, lwoodman, peterm, petrides, riel, tburke
Target Milestone: ---   
Target Release: ---   
Hardware: ia32e   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-07 12:09:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Oren Gimel 2005-01-16 09:01:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
When running uname -m on a em64t machine installed with an ia32e
kernel the output returning is x86_64.
This can trick `uname -m` aware Makefiles and seems like wierd
behaviour to me.
Is it really supposed to report that it's a x86_64?
If so why and how can I elsewhere probe my machine to understand that
it's a ia32e.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.run uname -m
2.
3.
    

Actual Results:  x86_64

Expected Results:  ia32e

Additional info:

Comment 1 Barry K. Nathan 2005-01-16 17:22:37 UTC
I don't have any ia32e boxes, but I imagine you could check
/proc/cpuinfo and see whether the vendor_id is GenuineIntel or
AuthenticAMD.

Comment 2 Ernie Petrides 2005-01-18 00:44:03 UTC
Thanks for your bug report, Oren.  We've been through this discussion
already, but I just can't remember what was decided.  I do remember
that this was considered a shortcoming in the "uname" command, so I'm
reassigning this to the "coreutils" component and maintainer.

Basically, the ia32e platforms are in fact a subset of the "x86_64"
architecture just as all x86 platforms are built from "i386".  So,
it's correct for "uname -m" to return "x86_64" on your ia32e box.

But I vaguely remember that the "uname -i" output is fabricated by
"uname" (taking into accout /proc/cpuinfo data), and that perhaps it
ought to distinguish between Opteron and EM64T cpus (which is doesn't
do currently).

Jim/Larry/Tim, any recollections about what we decided to do about this?
And do you remember the original bugzilla report for reference?


Comment 4 Jim Paradis 2005-01-19 05:47:17 UTC
I remember the issue, but I can't seem to find the original BZ either.  I do
remember, though, finding the special-case "athlon" code in the uname utility
and suggesting that it be cribbed for distinguishing x86_64/ia32e.


Comment 5 Tim Waugh 2005-01-28 14:41:13 UTC
I need more input before I can make any changes.

What option are we talking about changing, -i or -m?

What's the justification for making the change?

Comment 6 Ernie Petrides 2005-02-02 23:20:42 UTC
Hi, TimW.  I propose that the output of "uname -p" on a system with EM64T
cpus should be "ia32e" to disambiguate them from Opteron cpus.  This would
be exactly analogous to getting "athlon" (instead of "i686") from a "uname -p"
command on an Athlon-cpu-based x86 system.  JimP already discovered code in
"uname" that fabricated the "althlon" string based on /proc/cpuinfo data.

The justification for this change is that customers and install scripts
should have an easy way to tell which type of system it is, especially
for RPM installation purposes.  For example, an EM64T-based system running
RHEL3 needs to use, e.g., kernel-2.4.21-27.EL.ia32e.rpm instead of
kernel-2.4.21-27.EL.x86_64.rpm.

Comment 7 Tim Waugh 2005-02-03 11:06:50 UTC
Okay.  Now I just need to know what the test should be.

The current athlon-or-i686 test is (pseudo-code):

static char processor[257];
sysinfo (SI_ARCHITECTURE, processor, sizeof processor))
if (!strcmp(processor,"i686")) {
  read vendor_id from /proc/cpuinfo;
  if (!strcmp(vendor_id,"AuthenticAMD")
    strcpy(processor,"athlon");
}

What's the equivalent test I need to do for ia32e-or-x86_64?

Comment 8 Barry K. Nathan 2005-02-04 12:46:18 UTC
I still don't have any ia32e boxes, and all the Opterons I manage are in
production use, so I have no way of trying to test this. But, here goes
(psuedo-code, just like comment #7):

static char processor[257];
sysinfo (SI_ARCHITECTURE, processor, sizeof processor))
if (!strcmp(processor,"x86_64")) {
  read vendor_id from /proc/cpuinfo;
  if (!strcmp(vendor_id,"GenuineIntel")
    strcpy(processor,"ia32e");
}



Comment 9 Tim Waugh 2005-02-04 18:29:38 UTC
Okay, I've built coreutils-5.2.1-38 in dist-fc4.  If someone with an ia32e
machine could check it gives the right output that would be great.

Thanks.

Comment 10 Arjan van de Ven 2005-02-05 13:21:13 UTC
> Is it really supposed to report that it's a x86_64?

yes.

Tim: Please remove this patch again, it's entirely wrong.
Both AMD64 and Intel ia32e are of the x86_64 architecture.
Please do not add this weird patch.

> This can trick `uname -m` aware Makefiles and seems like wierd
>  behaviour to me.

Actually that's correct; both AMD64 cpus and Intel ones should use the
same architecture. So by changing uname one actually BREAKS such
makefiles.....


Comment 11 Arjan van de Ven 2005-02-05 13:29:23 UTC
(oh and in addition the intel name for their cpus is em64t not ia32e,
so ia32e is doubly wrong)

Comment 12 Barry K. Nathan 2005-02-05 23:11:28 UTC
Actually it looks like the Intel name for their CPU's, for now anyway,
is "Intel® Xeon⢠processor with Intel® EM64T" (exact quote):
http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/64bit/index.htm

Likewise, the Pentium 4 is the "Pentium 4 processor with Intel
NetBurst technology" (again, exact quote):
http://www.intel.com/pressroom/archive/releases/dp112000.htm

Returning "em64t" from uname -p on an ia32e/em64t CPU would be like
returning "netburst" on a Pentium 4, for better or worse...

OTOH, the phrase "em64t" seems to be used a *LOT* more by the
marketing literature for end users and purchasers (look at the how the
Dell Precision 670 is marketed on Dell's web site for instance). So
using "em64t" might be less confusing for people in the long run.

On the first hand again, Red Hat is already shipping "ia32e" RPM
packages in RHEL 3, so there may be some (short-term, I would hope)
confusion if Red Hat changes over to "em64t".

I guess my point is that the situation isn't quite as clear-cut as
comment #11 makes it out to be. At least, that's my opinion...

Comment 13 Arjan van de Ven 2005-02-06 09:04:42 UTC
your point is excellent and in support of my point in comment #10 ...
don't do this :) The distinction between athlon64, opteron and em64t
isn't worth coding in uname. It's a constantly changing playing field,
which would make uname -p entirely worthless, because one day we
return athlon64, the next week AMD changes the marketing names and we
return sempron. That makes it entirely impossible to use anywhere
realistically.

(and the original reported wanted to use it in some script. In that
case, x86_64 is the only right answer)

Comment 14 Tim Waugh 2005-02-07 12:09:32 UTC
Closing.