Bug 1254334
Summary: | Unreliable cpu detection through glibtop | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Helio Chissini de Castro <hcastro> | ||||
Component: | gnome-system-monitor | Assignee: | David King <dking> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.7 | CC: | asegundo, cww, jkoten, jmunilla, mboisver, tpelka | ||||
Target Milestone: | rc | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | gnome-system-monitor-2.28.0-13.el6 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-03-21 09:08:16 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: | 1172231 | ||||||
Attachments: |
|
Similar bug was opened for RHEL 7. This one contains the patch for the previous Gnome from RHEL 6 Reference on RHEL 7 https://bugzilla.redhat.com/show_bug.cgi?id=1254332 As the patch is already written, this is a very easy fix. While testing a multi-core machine with gnome-system-monitor-2.28.0-13.el6, I was able to see the correct amount of cores listed, as well as the idle cores at 0.0%. 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-2017-0578.html |
Created attachment 1064025 [details] Patch for RHEL 6 Gnome glibtop not provides the number of cpus on the machine directly, relying on a list with the current load of each core. Original code assume that a 0 load core is the end of cpu list, which is invalid in cases of machines with high number of cores, that happens to some cores stay idle with 0 load. Since this can happens in any core number, if a machine has 192 cores, but the core number 5 has 0 load, then 4 cores will be wrongly reported. Using standard sysconf api solves the issue in a simple way.