Problem:"lscpu frequency-info" command was always reading CPU0
max and min frequencies. If CPU0 is guarded or offline then it used to
display max and min frequencies as NULL.
This patch will read overall CPU max and min frequencies.
Test Results:
Before Patch:
#lscpu (CPU0 is guarded/offline)
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 120
On-line CPU(s) list: 8-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 32-63
NUMA node16 CPU(s): 64-95
NUMA node17 CPU(s): 96-127
With Patch:
# ./lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 120
On-line CPU(s) list: 8-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 4322.0000
CPU min MHz: 2061.0000
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 32-63
NUMA node16 CPU(s): 64-95
NUMA node17 CPU(s): 96-127
[kzak@redhat.com: - cpu_{max,min}_mhz() refactoring]
Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Windows 10 implements Windows Subsystem for Linux (WSL).
WSL does not implement support for SIGSEGV handler, which is used inside
is_vmware_platform(). As a result, lscpu crashes there.
Implement WSL detection, and as a side effect, work around the crash.
Note that none of existing virtualization types exactly matches.
But the the closest would be "container".
References:
Provide a way to positively detect WSL from an app compiled on Linux.
https://github.com/Microsoft/BashOnWindows/issues/423
missing support for SIGSEGV handler
https://github.com/Microsoft/BashOnWindows/issues/1637
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
It seems that aarch64 uses a different names for some /proc/cpuinfo
fields (e.g. intel: bogomips, flags, and aarch64: BogoMIPS, features, ...)
Addresses: https://github.com/karelzak/util-linux/issues/392
Signed-off-by: Karel Zak <kzak@redhat.com>
lscpu calculates the number of threads per core by dividing the number
of online cpus with the number of cores. This may or may not give the
correct number of threads per core depending on the number of online
CPUs (and which CPUs are online).
At least on s390 there is a new "max thread id" field within
/proc/cpuinfo present which reliably allows us to tell the number of
threads per core. Let's use this instead, like we already have also
special treatment to figure out the number core per socket etc. on
s390.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
lscpu can skip all CPUs which are possible but not present. For
configurations where a lot of CPUs are possible but only few CPUs are
present this saves a lot of pointless glibc/system calls.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
With the --physical option lscpu will use the IDs that are reported by
the kernel (e.g. core id for the CORE column) instead of calculating
them on it's own.
This has the advantage that it is possible to tell on which physical
hardware CPUs a Linux instance runs. The logical IDs that lscpu
generates on it own are based on comparing of CPU masks and may or may
not be identical with the physical IDs.
If the kernel was unable to retrieve an ID for a topology element then
the corresponding sysfs file will normally contain "-1". In the
extended and parsable output a dash "-" will be displayed for such
cases.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The Linux kernel exposes the cache topology via sysfs. However on
virtualized machines like s390 the cache topology contains only cpu
private caches.
For shared caches it is not known which cpus share them. The
hypervisor would have to update this information whenever a virtual
cpu would be scheduled on a different physical cpu and make the guest
aware of that change. Given that there is hardly any benefit, if it
all, this isn't done.
However it is still of interest to know about the non-private
caches. Therefore this information is available via /proc/cpuinfo at
least on s390.
This patch adds additional lines to the summary output for all shared
caches for which information can be found in /proc/cpuinfo, since we
know these aren't exposed via sysfs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Show also the machine type within the lscpu output. With the machine
type it is possible to identify the cpu generation and the supported
features.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
s390 machines provide static and dynamic cpu mhz information via
/proc/cpuinfo. The static cpu mhz is the normal cpu frequency a cpu is
supposed to run with.
The dynamic cpu mhz is the actual frequency a cpu is running
with. This is usually the same as the static cpu mhz. Note that this
values are different to the min/max mhz values available on other
architecutes. The min/max values are unknown.
This patch adds two new fields to the summary output which display
these two values.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The new drawer support did have a type in the summary output:
it reported Drawers(s) instead of Drawer(s). Fix this.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The s390 architecture gained another cpu topology level called
"drawer" which is above the book level.
Add support for this to lscpu.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Fix various typos in error messages, warnings, debug strings,
comments and names of static functions.
Signed-off-by: Sebastian Rasmussen <sebras@gmail.com>
Nowadays, most Intel CPUs have "cpuid faulting" available which could trap
the execution of "cpuid" instruction when CPL>0 with GP fault. Thus,
"cpuid" instruction could trap to Xen hypervisor on the paravirtualized PV
guest on most servers today, except on old CPUs prior to 2011. On CPU after
2011, Xen will put "XenVMMXenVMM" on both HVM and PV guests, which could
have lscpu command erroneously classify the guest as type "full". The
current lscpu command, which is based on "cpuid" instruction, still assumes
that it will not cause the trap to Xen hypervisor on Xen PV guest and uses
/proc/xen to identify whether it's running on PV DomU or not. To identify
this kind of information under the help of
/sys/hypervisor/properties/features would be more accurate for the CPU
nowadays. The bit 5 (XENFEAT_mmu_pt_update_preserve_ad) of the features
will be set only when it's running on Xen PV domain. The combo of bit 3 and
8 (XENFEAT_supervisor_mode_kernel and XENFEAT_hvm_callback_vector) will be
set simultaneously only when it's running on Xen PVH domain.
[kzak@redhat.com: - add path_exist()]
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Now the first one of certain ambiguous tags wins. Alternatively to
this patch we could have called free() before xstrdup().
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Avoid ifdef which does not work with --sysroot. Our existing test
dumps produce even better output now for ppc and sparc.
The logic moved to the printing section.
CC: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This patch reverts 3ac03fe4d2 for
snapshots (--sysroot).
Yeah, poor-man solution. It would be really nice to have runtime
detection to support model overwriting also on snapshots.
Signed-off-by: Karel Zak <kzak@redhat.com>
On Power System, lspcu presently displays system model number instead of
processor model name. 'model' tag in cpuinfo contains system model name,
not processor model. Instead it uses 'cpu' tag for processor model name.
Also it uses 'revision' tag for processor model.
Fix lspcu so that it displays processor model number. Also display processor
model name.
cpuinfo output on Power System:
...
...
processor : 127
cpu : POWER8E (raw), altivec supported
clock : 4322.000000MHz
revision : 2.1 (pvr 004b 0201)
timebase : 512000000
platform : PowerNV
model : 8286-42A
machine : PowerNV 8286-42A
firmware : OPAL
Output without this patch:
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 4
NUMA node(s): 4
Model: 8286-42A
...
...
Output with this patch:
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
...
...
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
lscpu currently prints information for CPUs configured in the system.
In case of KVM or other virtualized guest operating systems, this
refers to the virtual system, and bears no relation to the physical
topology of the system.
It would be useful if lscpu could also display the physical topology
info when available:
$ ./lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 16
NUMA node(s): 1
Model: IBM pSeries (emulated by qemu)
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 64K
L1i cache: 32K
NUMA node0 CPU(s): 0-15
Physical sockets: 2 <<< New
Physical chips: 4 <<< New
Physical cores/chip: 4 <<< New
For now, physical topology information is available on platforms that
support the following RTAS (Real time abstraction service) call provided
by librtas:
rtas_get_sysparm(PROCESSOR_MODULE_INFO).
Currently this call is available to the PowerVM (pHYP) guests on PowerPC.
With a patch propoosed to PowerKVM, this RTAS call would also be available
to PowerKVM guests.
Based on input from Nishanth Aravamudan and Karel Zak.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
We care about /proc/device-tree/compatible content...
The patch also removes unnecessary path_exist(), it seems good enough
to call open() rather than access() + open().
Addresses: https://github.com/karelzak/util-linux/issues/218
Signed-off-by: Karel Zak <kzak@redhat.com>
Intel compiler complains about printf style function calls with trivial
format string and no other arguments. Like this one:
../sys-utils/ipcrm.c(117): warning #2279: printf/scanf format not a string literal and no format arguments
err(EXIT_FAILURE, iskey ? _("key failed") : _("id failed"));
This adds a concise description of a tool to its usage text.
A first form of this patch was proposed by Steven Honeyman
(see http://www.spinics.net/lists/util-linux-ng/msg09994.html).
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
AddressSanitizer is identifying the __asm__ segment as suspicious.
==1215==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x0000004ccffd bp 0x7fff9b7184f0 sp 0x7fff9b7184e0 T0)
#0 0x4ccffc in vmware_bdoor /home/src/util-linux/sys-utils/lscpu.c:660
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
there is a theoretical buffer overflow possible in the hypervisor
parsing code of lscpu. It would require a proc entry to return way more
than expected so it's no high priority. But better be safe than sorry.
At first I thought about switching to fgets but there is another
code file that adds a format specifier. The diff is less intrusive
that way, too.
Signed-off-by: Karel Zak <kzak@redhat.com>
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>