Bug 145266
Summary: | ia32e kernel returns x86_64 in uname | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Oren Gimel <oren> |
Component: | coreutils | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | 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
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. 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? 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. 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? 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. 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? 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"); } 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. > 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..... (oh and in addition the intel name for their cpus is em64t not ia32e, so ia32e is doubly wrong) 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... 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) Closing. |