Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1094749 - rhn-client-tools does not properly count CPU socket information
Summary: rhn-client-tools does not properly count CPU socket information
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 2.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space22
TreeView+ depends on / blocked
 
Reported: 2014-05-06 12:07 UTC by Milan Zázrivec
Modified: 2019-04-16 14:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1093157
Environment:
Last Closed: 2014-07-17 08:41:21 UTC
Embargoed:


Attachments (Terms of Use)

Description Milan Zázrivec 2014-05-06 12:07:56 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 Milan Zázrivec 2014-05-06 12:23:24 UTC
spacewalk.git master: 7eeef9a01c6fea22f80313b0d79f12e21fc556e7

Comment 2 Milan Zázrivec 2014-07-17 08:41:21 UTC
Spacewalk 2.2 has been released:

    https://fedorahosted.org/spacewalk/wiki/ReleaseNotes22


Note You need to log in before you can comment on or make changes to this bug.