Bug 145266 - ia32e kernel returns x86_64 in uname
ia32e kernel returns x86_64 in uname
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: coreutils (Show other bugs)
ia32e Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2005-01-16 04:01 EST by Oren Gimel
Modified: 2007-11-30 17:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-07 07:09:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Oren Gimel 2005-01-16 04:01:25 EST
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:

Steps to Reproduce:
1.run uname -m

Actual Results:  x86_64

Expected Results:  ia32e

Additional info:
Comment 1 Barry K. Nathan 2005-01-16 12:22:37 EST
I don't have any ia32e boxes, but I imagine you could check
/proc/cpuinfo and see whether the vendor_id is GenuineIntel or
Comment 2 Ernie Petrides 2005-01-17 19:44:03 EST
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 00:47:17 EST
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 09:41:13 EST
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 18:20:42 EST
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
Comment 7 Tim Waugh 2005-02-03 06:06:50 EST
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")

What's the equivalent test I need to do for ia32e-or-x86_64?
Comment 8 Barry K. Nathan 2005-02-04 07:46:18 EST
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")

Comment 9 Tim Waugh 2005-02-04 13:29:38 EST
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.

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


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
Comment 11 Arjan van de Ven 2005-02-05 08:29:23 EST
(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 18:11:28 EST
Actually it looks like the Intel name for their CPU's, for now anyway,
is "Intel® Xeon™ processor with Intel® EM64T" (exact quote):

Likewise, the Pentium 4 is the "Pentium 4 processor with Intel
NetBurst technology" (again, exact quote):

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 04:04:42 EST
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

(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 07:09:32 EST

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