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
Created attachment 891273 [details] Patch to count the unique physical ids Attached proposed patch to count the unique physical ids iso. determining the highest id in /proc/cpuinfo
Although less obvious since RHEL6 is shipped with lscpu as part of the util-linux-ng package, same issue is present in RHEL6 as well.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
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. http://rhn.redhat.com/errata/RHBA-2014-1215.html