Bug 1094777

Summary: rhn-client-tools does not properly count CPU socket information
Product: Red Hat Enterprise Linux 7 Reporter: Milan Zázrivec <mzazrivec>
Component: rhn-client-toolsAssignee: Stephen Herr <sherr>
Status: CLOSED NOTABUG QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: cperry, jhutar, rvdwees
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1093157 Environment:
Last Closed: 2014-09-17 19:39:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1082754, 1113520    

Description Milan Zázrivec 2014-05-06 13:17:33 UTC
+++ This bug was initially created as a clone of Bug #1093157 +++

Description of problem: With bz#949617 as released with RHEL5.10, the CPU
socket information is now being reported to Satellite 5.6. However the socket
count using /proc/cpuinfo is not always correctly counted because the
"physical id" is not always a full ascending sequence.

Version-Release number of selected component (if applicable):
rhn-client-tools-0.4.20.1-6.el5

How reproducible:
Always but depends on the hardware

Steps to Reproduce:
1. Register a physical machine with multiple sockets, multi core RHEL5 machine
   against 5.6 Satellite, i.e. a 2 socket with 2 cores per cpu
2. Run rhn-profile-sync
3. Check the System -> Details -> Hardware

Actual results:
Sockets:    4
Cores:      4

Expected results:
Sockets:    2
Cores:      4


Additional info:
The '__get_number_sockets() function from
rhn-client-tools-0.4.20.1/src/up2date_client/hardware.py tries different
methods to determine the sockets count:
1. /usr/bin/lscpu
2. /proc/cpuinfo
3. /usr/sbin/dmidecode

On RHEL5, lscpu does not exist and falls back to searching the highest
"physical id" in /proc/cpuinfo:

 485     # Next try parsing /proc/cpuinfo
 486     if os.access("/proc/cpuinfo", os.R_OK):
 487         try:
 488             lines = open("/proc/cpuinfo", 'r').readlines()
 489             max_socket_index = -1
 490             for line in lines:
 491                 if 'physical id' in line:
 492                     socket_index = int(line.split(':')[1].strip())
 493                     if socket_index > max_socket_index:
 494                         max_socket_index = socket_index
 495             if max_socket_index > -1:
 496                 return 1 + max_socket_index
 497         except:
 498             pass


However this "physical id" is not fully sequential on all hardware. I.e. a
BL460G1 with two sockets and 2 cores / socket:

$ grep BL460 dmidecode 
	Product Name: ProLiant BL460c G1

$ grep "^physical id" proc/cpuinfo 
physical id	: 0
physical id	: 3
physical id	: 0
physical id	: 3

Comment 1 Stephen Herr 2014-09-17 19:39:15 UTC
This is not a bug on RHEL 7. See https://bugzilla.redhat.com/show_bug.cgi?id=1093157#c6

This was only a problem on RHEL 5 because lscpu was not included. On RHEL 7 lscpu is installed by util-linux (which you cannot uninstall). We use lscpu if it is present, so we will never try to parse /proc/cpuingo outselves on RHEL 7.