After tested on different platforms, we found dmi_string() may return NULL
in some case.
So add more sanity checks for dmi_decode_cputype().
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
In the arm platform, we do not have the "CPU family" as X86.
In the linux kernel, it is hardcode to set the "CPU architecuture:8"
which should be changed for arm v9 in future.
This patch adds "bios_family" field, which we can get from the DMI table.
In the ampere Altra platform, we can get the new lscpu output:
----------------------------------------------------------------
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Vendor ID: ARM
BIOS Vendor ID: Ampere(R)
Model name: Neoverse-N1
BIOS Model name: Ampere(R) Altra(R) Processor Q00-00 CPU @ 3.0GHz
BIOS CPU family: 257
Model: 1
Thread(s) per core: 1
----------------------------------------------------------------
[kzak@redhat.com: - s/sprintf/snprintf/]
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The patch :367c85c47286 ("lscpu: use SMBIOS tables on ARM for lscpu")
relies on the existence of "/sys/firmware/dmi/entries/4-0/raw",
which may not exist in standard linux kernel.
But "/sys/firmware/dmi/tables/DMI" should exist and can provide the required
processor information.
This patch uses "/sys/firmware/dmi/tables/DMI"
to get the processor information:
Before this patch, in Ampere Altra platform, the lscpu output is:
---------------------------------------------
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Vendor ID: ARM
Model name: Neoverse-N1
Model: 1
Thread(s) per core: 1
Core(s) per socket: 80
Socket(s): 2
........................................
---------------------------------------------
After this patch, we can use get the lscpu output
in Ampere Altra platform:
---------------------------------------------
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 160
On-line CPU(s) list: 0-159
Vendor ID: ARM
BIOS Vendor ID: Ampere(R)
Model name: Neoverse-N1
BIOS Model name: Ampere(R) Altra(R) Processor Q00-00 CPU @ 3.0GHz
Model: 1
Thread(s) per core: 1
Core(s) per socket: 80
Socket(s): 2
........................................
---------------------------------------------
[kzak@redhat.com: - s/sprintf/snprintf/]
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Add a helper function, get_number_of_physical_sockets_from_dmi(),
to get physical sockets from DMI table in case of the sysfs for
cpu topology doesn't have the physical socket information.
get_number_of_physical_sockets_from_dmi() parse the DMI table
and counts the number of SMBIOS Processor Information (Type04)
structure.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
ARM SBBR (Sever Base Boot Requirements) require SMBIOS tables, and
SMBIOS Type 4 describes the CPU manufacturer and model name (among other
details). If SMBIOS Type 4 is present, use it to extract these strings.
Example output (before and after the patch) on an HP m400, Lenovo HR330A,
and HPE Apollo 70:
[root@hp-m400 ~]# /usr/bin/lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: APM
Model: 1
Model name: X-Gene
Stepping: 0x0
[root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: AppliedMicro
Model: 1
Model name: X-Gene
Stepping: 0x0
[root@lenovo-hr330a ~]# /usr/bin/lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: APM
Model: 2
Model name: X-Gene
Stepping: 0x3
[root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: Ampere(TM)
Model: 2
Model name: eMAG
Stepping: 0x3
[root@hpe-apollo-70 ~]# /usr/bin/lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: Cavium
Model: 1
Model name: ThunderX2 99xx
Stepping: 0x1
[root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping
Vendor ID: Cavium Inc.
Model: 1
Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 @ 2.20GHz
Stepping: 0x1
[kzak@redhat.com: - move dmi_header to lscpu.h
- make arm_cpu_smbios() more robust for failed
open() and read()
- use original arm_cpu_decode() also on failed
arm_cpu_smbios()]
Signed-off-by: Jeffrey Bastian <jbastian@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
With pointer arithmetic clang address sanitizer gives following error this
change addresses. Notice the following happens only when running as root.
sys-utils/lscpu-dmi.c:83:14: runtime error: load of misaligned address
0x55a1d62f3d1d for type 'const uint16_t' (aka 'const unsigned short'), which
requires 2 byte alignment
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Michal wrote:
There is weird mix of logic in lscpu-dmi.c which sometimes returns 0 and
sometimes -1 on error. Since most checks are if (rc) goto done; this
bails out early on error skipping some detection methods. Further, in
lscpu.c all following detections are guarder by if(hyper) so returning
-1 causes all following methods to be skipped.
Reported-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Karel Zak <kzak@redhat.com>
On ARM systems, accessing SMBIOS tables via /dev/mem using read()
calls is not supported. The reason is that such tables are usually
located in EFI_RUNTIME_SERVICE_DATA memory, which is not covered
by the linear mapping on those systems, and so read() calls will
fail.
So instead, use the /sys/firmware/dmi/tables/DMI sysfs file, which
contains the entire structure table array, and will be available
on any recent Linux system, even on ones that only export the rev3
SMBIOS entry point, which is currently ignored by lscpu.
Note that the max 'num' value is inferred from the size. This is not
a limitation of the sysfs interface, but a limitation of the rev3
entry point, which no longer carries a number of array elements.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
CppCheck founds a few wrong arguments in format strings and a NULL
pointer dereference.
Amended version with fixed strcmp() usage.
Signed-off-by: Boris Egorov <egorov@linux.com>
Most of them catched on 32bit gcc and icc.
disk-utils/fsck.cramfs.c: printf format type
lib/boottime.c: unused variables
misc-utils/cal.c: set but never used
sys-utils/losetup.c: set but never used
sys-utils/lscpu-dmi.c: defined but not used
sys-utils/switch_root.c: comparison between signed and unsigned
tests/helpers/test_sysinfo.c: printf format type
As the comment in the code says, this method is really only valid
on x86 and x86_64, so add a #ifdef for those architectures around
that code block.
This was causing "Program lscpu tried to access /dev/mem between f0000->100000."
warnings on some ppc64 machines.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Huang Shijie
Masayoshi Mizuma
Karel Zak
Jeffrey Bastian
Sami Kerola
Ard Biesheuvel
Boris Egorov
Ruediger Meier
Stewart Smith
Ondrej Oprala