View Issue Details

IDProjectCategoryView StatusLast Update
0015108CentOS-7kernelpublic2018-08-14 18:04
Reporterjwaynej Assigned To 
PrioritynormalSeveritymajorReproducibilityunable to reproduce
Status newResolutionopen 
Product Version7.4.1708 
Summary0015108: cpu core counts change unexpectedly
DescriptionWe have had a half dozen instances recently where various [parallel] applications get a floating point exception on launch. The only thing we have found in common is that 'cpu cores' as reported in /proc/cpuinfo has somehow become corrupted. Rebooting fixes the issue.

For example:

[root@mlhw7abx ~]# grep cores /proc/cpuinfo
cpu cores : 4
cpu cores : 7
cpu cores : 6
cpu cores : 5

The above is incorrect. The correct answer is 4 cores, for all CPUs. Not sure how its possible to increase the cor

This has happened on at least a 3 different models of HP Z-series workstations with different generation Xeon procs. Hyperthreading is disabled in BIOS. So far everything that has had the issue is using EFI firmware, not legacy BIOS. End-users do not have sudo/root access.

Steps To ReproduceWe have not found a way to reproduce on demand yet.
TagsNo tags attached.




2018-07-30 04:08

reporter   ~0032392

A couple of updates:

After looking at over 2000 deployed systems, we found that the problem is not confined to EFI-based systems. About 1% of the systems were affected. Rebooting always fixes 'cpu cores'.

Tools like 'nproc', 'lscpu', and 'numctl' always show the correct socket/core count.

It seems this issue is confined to /proc/cpuinfo (procfs).

Another example (different system):

This is wrong:
[root@mlhw70rx ~]# grep cores /proc/cpuinfo
cpu cores : 4
cpu cores : 7
cpu cores : 6
cpu cores : 5
cpu cores : 7
cpu cores : 6
cpu cores : 5
cpu cores : 4

Everything else is right:
[root@mlhw70rx ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Model name: Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz
Stepping: 7
CPU MHz: 3396.937
CPU max MHz: 3500.0000
CPU min MHz: 1200.0000
BogoMIPS: 6583.94
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 10240K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb spec_ctrl ibpb_support tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts

[root@mlhw70rx ~]# numactl --show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7
cpubind: 0 1
nodebind: 0 1
membind: 0 1

[root@mlhw70rx ~]# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3
node 0 size: 32691 MB
node 0 free: 220 MB
node 1 cpus: 4 5 6 7
node 1 size: 32768 MB
node 1 free: 85 MB
node distances:
node 0 1
  0: 10 20
  1: 20 10


2018-08-14 18:04

reporter   ~0032487

I noticed that the latest kernel released for RHEL7 has this bug fix:

  Previously, when a user performed a CPU hotplug, the /proc/cpuinfo virtual file
  displayed an incorrect number of cores. With this update, the number of cores
  is initialized when a CPU hotplug occurs. As a result, /proc/cpuinfo displays
  the correct number of cores in the described scenario. (BZ#1588563)

It's unclear if this is the same issue, as its user is not hotplugging CPUs, but it could be related. The BZ is still private.

Issue History

Date Modified Username Field Change
2018-07-26 23:34 jwaynej New Issue
2018-07-30 04:08 jwaynej Note Added: 0032392
2018-08-14 18:04 jwaynej Note Added: 0032487