Bug 1094776

Summary: rhn-client-tools does not properly count CPU socket information
Product: Red Hat Enterprise Linux 6 Reporter: Milan Zázrivec <mzazrivec>
Component: rhn-client-toolsAssignee: Matej Kollar <mkollar>
Status: CLOSED ERRATA QA Contact: Pavel Studeník <pstudeni>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.6CC: cperry, dyordano, jhutar, mkollar, pstudeni, rvdwees
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: rhn-client-tools-1.0.0.1-29-el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1093157 Environment:
Last Closed: 2015-07-22 07:28:50 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:

Description Milan Zázrivec 2014-05-06 13:15:57 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 4 Pavel Studeník 2015-04-07 13:13:06 UTC 
Reproducer on RHEL6

# yum remove subscription-manager

and you need remove package with command lscpu 

# rpm -qf /usr/bin/lscpu
util-linux-ng-2.17.2-12.18.el6.x86_64

and removing util-linux-ng is not good idea for RHEL6

Then patch works correctly (I remove /usr/bin/lscpu)

Sockets: 	4

Verified with rhn-client-tools-1.0.0.1-32.el6.noarch.rpm

Sockets: 	2
Comment 5 errata-xmlrpc 2015-07-22 07:28:50 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1395.html