Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1253842 - [aarch64] lscpu shows 4 sockets on a single socket SoC
Summary: [aarch64] lscpu shows 4 sockets on a single socket SoC
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: aarch64
OS: Unspecified
Target Milestone: ---
Assignee: Jon Masters
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2015-08-14 21:22 UTC by Richard W.M. Jones
Modified: 2019-03-05 14:01 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2019-03-05 14:01:52 UTC
Type: Bug

Attachments (Terms of Use)
dmesg (33.76 KB, text/plain)
2015-08-14 21:27 UTC, Richard W.M. Jones
no flags Details
proc.tar.gz (938.41 KB, application/x-gzip)
2015-09-01 05:48 UTC, Richard W.M. Jones
no flags Details
sys.tar.gz (1.57 MB, application/x-gzip)
2015-09-01 05:48 UTC, Richard W.M. Jones
no flags Details
mustang.tar.gz (3.43 KB, application/x-gzip)
2015-09-01 05:50 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2015-08-14 21:22:25 UTC
Description of problem:

This is on Fedora Rawhide aarch64.  The hardware is the APM Mustang.

# lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             4

This system is definitely not 4 sockets :-)  It has a single
system on chip (SoC), ie. 1 socket, with 8 real cores (no threads).

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

kernel 4.0.7-300.fc22.aarch64

Comment 1 Richard W.M. Jones 2015-08-14 21:27:28 UTC
With kernel 4.2.0-0.rc2.git0.1.fc23.aarch64 the output is the same:

# lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             4

I'm attaching the dmesg output in case that is useful.

Comment 2 Richard W.M. Jones 2015-08-14 21:27:55 UTC
Created attachment 1063171 [details]

Comment 3 Don Dutile (Red Hat) 2015-08-14 23:30:13 UTC
Currently, the report by lspu, which is derived from the cpu topology under sysfs, is comprised from two possible sources:
-- DT entries, which are often not filled out;
    -- but more of it is getting filled out for NUMA-based machines/SoCs,
       b/c correct cpu tolopolgy is critical for the kernel numa code to
    -- note: ACPI-based NUMA specification, SRAT, solves most of the issue
             except for the next field & its correlation to SRAT-cpu-values.
-- MPIDR Aff<x> fields.

On ARMv8, unlike ARMv7, MPIDR contents are *implementation specific* -- an architected register w/un-architected contents.  duh!
ARMv7 had a simple spec that lower 8-bits(Aff0) were cores, next 8 bits(Aff1) were 'clusters' that shared L2 caches; I think the Aff3 field was for shared L3. But since 99.999999% of ARMv7's are single socket, relative small core counts, it was easy to make the MPIDR register go from unspecified to 'we all agree to do it this way' ... b/c they happen to do it that way.

On ARMv8, the upstream topology code in interpreting Aff1 as the socket count,
when in fact, it is a 'cluster' index, indicating shared caches.

If you run the same command on a RHELSA kernel, you will find proper values, because RHELSA is carrying a patch that works for Xgene & Seattle.  IIRC, that patch will fail for ThunderX, and will need further modification.

jcm has a to-do on this issue w/ARM & to come up with an ACPI-based solution that will yield the equivalent of x86's cpu-id -based, cpu topology information. [read the arch/x86/kernel/topology.c code to learn the details, and search the Intel tech pages for a paper on their topology architecture wrt cpu-id probing.  The DT-based solution is TBD, and the DT-huggers can resolve it with yet-another-specification-to-cpu-DT.

Until ARM & it's partners determine/specify/require an architected cpu topology specification, this problem becomes a per-SoC, 'quirk' to the arch/arm64/kernel/topology.c support.

Comment 4 Karel Zak 2015-08-17 10:23:27 UTC
So if I read correctly Don's comment #3 then the problem is mostly in stuff exported by kernel in /sys and for patched kernels (e.g. RHELSA) lscpu generates valid output. Right?  ... then it's time to reassign to kernel :-)

Richard, it would be nice to have /sys and /proc dump from the system, in upstream tree we have a script

to create a tarball. Please, send me (or add to BZ) the tarball.

Comment 5 Richard W.M. Jones 2015-09-01 05:48:00 UTC
Created attachment 1068857 [details]

Comment 6 Richard W.M. Jones 2015-09-01 05:48:30 UTC
Created attachment 1068858 [details]

Comment 7 Richard W.M. Jones 2015-09-01 05:50:59 UTC
Created attachment 1068859 [details]

I should have read the whole comment before posting those
previous attachments.  Attached is the output from the command

sudo ./ mustang

Comment 8 Jeremy Linton 2019-03-04 22:04:58 UTC
This is an old one, and while not fixed on the mustang, should be fixed on any aarch64/ACPI machine with a correct PPTT.

It maybe worth closing this.

Comment 9 Laura Abbott 2019-03-05 14:01:52 UTC
Thanks. I'm going to close this then. I think the best approach would be to reopen for specific machines that don't have a correct PPTT is problems still show up.

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