RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1447460 - Uname -m returns arm for that processor, but uname -p returns Unknown ????? why ?
Summary: Uname -m returns arm for that processor, but uname -p returns Unknown ????? w...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: coreutils
Version: 7.5-Alt
Hardware: arm
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-02 21:24 UTC by Don Capps
Modified: 2017-05-15 16:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-15 16:20:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 548834 0 low CLOSED uname -i started returning unknown 2022-08-23 12:38:33 UTC

Internal Links: 548834

Description Don Capps 2017-05-02 21:24:18 UTC 
Description of problem:

uname -m returns "arm" for that processor family, but uname -p returns "unknown"   Why ? This seems inconsistent with the man page for uname.

The man page for uname states that -p returns the processor type. Which, is clearly known as uname -m is already returning this string. The -m returns "machine" which is an ill defined term and inconsistent across the industry.
The returned values from uname -p are far more consistent across operating systems.  Example: On AIX uname -m  returns 98787687y459  but uname -p returns "powerpc".   Uname -m on MacOS returns "Macintosh x86_64" but uname -p returns "x86_64"  Uname -m on Solaris returns "i86pc" but Uname -p returns "i386"  and similar for other operating systems.  The uname -p is clearly more consistent than the -m option.  
It seems even more strange that Linux would have uname -p return x86_64 on Intel, but "unknown" on ARM, when the same boxes will return x86_64 for the -m option on Intel, and "unknown" on ARM.  So there is inconsistency even within the same version of Linux.... 

Version-Release number of selected component (if applicable):
All versions that support ARM processors.

How reproducible:
Very.

Steps to Reproduce:
1.uname -p on any ARM based system.


Actual results:
# uname -m
armv7l
# uname -p
unknown
[~] #


Expected results:
arm, arm71, armv71 anything that matches what uname -m is returning would be better than "unknown" :-)

Additional info:
Comment 2 Kamil Dudka 2017-05-03 10:22:28 UTC 
I tried it on aarch64 and it worked as expected:

# rpm -q coreutils
coreutils-8.22-18.el7.aarch64

# uname -m
aarch64

# uname -p
aarch64

# uname -a
Linux hp-moonshot-02-c06.khw.lab.eng.bos.redhat.com 4.5.0-15.4.2.el7.aarch64 #1 SMP Wed Mar 22 15:58:27 EDT 2017 aarch64 aarch64 aarch64 GNU/Linux

Please provide the output for the above commands captured on your system.
Comment 3 Don Capps 2017-05-03 13:35:13 UTC 
#rpm -q coreutils
command not found   
<<< I'm using a small embedded version of Linux on a system with small amounts of RAM. So, some commands are not present >>>>

Actual output:

# uname -m
armv7l

# uname -p
unknown

------------- 
Do you have an arm7l where you can check this ? or perhaps just take a peek at the source code for uname and see if it supports all of the various ARM processor types ?  

Note: Wikipedia also tries to show all of the various uname outputs, across the various Operating systems, and versions of operating systems. See: https://en.wikipedia.org/wiki/Uname
Comment 4 Kamil Dudka 2017-05-03 14:07:31 UTC 
(In reply to Don Capps from comment #3)
> #rpm -q coreutils
> command not found   
> <<< I'm using a small embedded version of Linux on a system with small
> amounts of RAM. So, some commands are not present >>>>

I need to know exactly which build of coreutils (RPM package) you are using.  If you are able to get the output of strace for the above commands, it would also help.  Note that you forgot to paste the output of 'uname -a'.

> Do you have an arm7l where you can check this ?

I am not sure.

> or perhaps just take a peek
> at the source code for uname and see if it supports all of the various ARM
> processor types ?

The original source code of uname(1) distributed with coreutils-8.22 is here:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/uname.c;hb=v8.22

Fedora and RHEL apply the following patch on top of that:

https://src.fedoraproject.org/cgit/rpms/coreutils.git/tree/coreutils-8.2-uname-processortype.patch?id=34aa7594

> Note: Wikipedia also tries to show all of the various uname outputs, across
> the various Operating systems, and versions of operating systems. See:
> https://en.wikipedia.org/wiki/Uname

It is not clear which implementation of uname(1) the wiki page describes.  RHEL-7 implementation differs from upstream.  See the patch above.
Comment 5 Kamil Dudka 2017-05-03 15:10:00 UTC 
Looking closer at the patch, it falls back to 'uname -m' for the -p/-i options in case sysinfo() cannot be used to obtain the requested information.  It just hides the actual problem, instead of printing "unknown" as documented.

The documentation was later improved upstream to make it clear that the -p and -i options are non-portable:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-7-g6d67649
Comment 6 Kamil Dudka 2017-05-15 15:44:18 UTC 
Don, could you please verify that you are really using the uname implementation provided by a Red Hat supported coreutils package?

I would expect the patched code to return the same output for 'uname -p' as for 'uname -m' instead of returning "unknown".
Comment 7 Don Capps 2017-05-15 15:50:06 UTC 
The system that demonstrated the uname-p problem has been de-installed.
So.. We can either close the bug, or try to find another arm71 based
system to restart the debug.

Thank you,
Don Capps
Comment 8 Kamil Dudka 2017-05-15 16:20:52 UTC 
Thanks for reply!  I am closing the bug now.  Feel free to reopen once you have the requested info...
Note You need to log in before you can comment on or make changes to this bug.