View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015108 | CentOS-7 | kernel | public | 2018-07-26 23:34 | 2018-08-14 18:04 |
Reporter | jwaynej | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | unable to reproduce |
Status | new | Resolution | open | ||
Product Version | 7.4.1708 | ||||
Summary | 0015108: cpu core counts change unexpectedly | ||||
Description | We 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 Reproduce | We have not found a way to reproduce on demand yet. | ||||
Tags | No tags attached. | ||||
abrt_hash | |||||
URL | |||||
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 |
|
I noticed that the latest kernel released for RHEL7 has this bug fix: https://access.redhat.com/articles/3527791 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. |
|