After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 619732 - gnome-system-monitor does not show CPU speed on ppc64
gnome-system-monitor does not show CPU speed on ppc64
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: sysinfo
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-26 15:41 UTC by Luciano Chavez
Modified: 2011-11-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch to obtain "clock" info and append to "cpu" info if it exists (1.06 KB, patch)
2010-05-28 03:17 UTC, Luciano Chavez
none Details | Review
Screenshot of cpu speed displayed on ppc64 using patched gnome-system-monitor (39.43 KB, image/png)
2010-05-28 18:39 UTC, Luciano Chavez
  Details
Updated patch (1.05 KB, patch)
2011-06-21 16:51 UTC, Luciano Chavez
none Details | Review

Description Luciano Chavez 2010-05-26 15:41:38 UTC
I am looking at problem reported by one of our test teams. Below is
their recreation steps and what they reported:

1. Launch System Monitor Tool (gnome-system-monitor-2.28.0)
2. Look at "Hardware" item of "System" tabbed section like following sentence:
Precessor 0: POWER6 (architected), altivec supported ===> no processor speed
3. In System Monitor Tool window, open help manual via
Help->Contents->Introduction and you could see "Processors and speeds"
description in "Hardware" item of "System" tabbed section

Here is my analysis:

I took a look at the source for gnome-system-monitor and determined where the
strings that are displayed came from. Looking at src/sysinfo.cpp there is this
method:

    void load_processors_info()
    {
      const glibtop_sysinfo *info = glibtop_get_sysinfo();

      for (guint i = 0; i != info->ncpu; ++i) {
        const char * const keys[] = { "model name", "cpu" };
        gchar *model = 0;

        for (guint j = 0; !model && j != G_N_ELEMENTS(keys); ++j)
          model =
static_cast<char*>(g_hash_table_lookup(info->cpuinfo[i].values,
                                                         keys[j]));

        if (!model)
          model = _("Unknown CPU model");

        this->processors.push_back(model);
      }
    }

It first invokes the glibtop_get_sysinfo() call which comes from the external
libgtop to retrieve the system info (I will explain where from shortly) and
then uses the keys "model name" and "cpu" to retrieve the corresponding strings
in a hash table that correspond to those keys. What is retrieved is what ends
up being displayed under the Hardware section.

In the libgtop source we find a file called  sysdeps/linux/sysinfo.c which
contains the source for the glibtop_get_sysinfo() which almost wholly contained
in the function init_sysinfo() which essentially reads the contents of
/proc/cpuinfo into a buffer then parses each line and uses the label before the
":" as the key and the remaining as the value and the labels/keys are loaded
into string array and the string values are added into a hash table with the
label as the key.

So, looking at the /proc/cpuinfo of a x86_64 system I get the following:

model name      : Intel(R) Xeon(TM) CPU 3.40GHz

as well as ...

cpu MHz         : 3400.000

but on the test system we get

cpu             : POWER6 (architected), altivec supported
clock           : 4204.000000MHz

So, as you can see  both do offer separate sysinfo records for the processor
speed ("cpu MHz" and "clock") but since only "model name" and "cpu" are looked
at and only "model name" contains that extra info, this is why for the ppc64
system, it is not displayed though it is separately available from the "clock"
record.

I am considering creating a patch for the case when "model name" is not
available but "cpu" is which will simply append the "clock" text (if
available) to the "cpu" text.
Comment 1 Luciano Chavez 2010-05-28 03:17:12 UTC
Created attachment 162164 [details] [review]
Proposed patch to obtain "clock" info and append to "cpu" info if it exists

Here is the proposed patch to allow displaying the cpu speed with the cpu model similar to model name information. 

I have compiled it and tried it on an x86_64 system which provides "model name" and the behavior remains unchanged as expected. 

I am still trying to obtain a ppc64 system to test the change there to see if it works as expected. I will provide that feedback once it has been tested on a ppc64 host.
Comment 2 Luciano Chavez 2010-05-28 18:39:43 UTC
Created attachment 162234 [details]
Screenshot of cpu speed displayed on ppc64 using patched gnome-system-monitor

I was able to test the patch on a pp64 host and it appears to fix the problem,
displaying the cpu clock speed.
Comment 3 Luciano Chavez 2011-02-11 17:14:04 UTC
Hello,

Is it possible to get a comment regarding the patch please? Thanks.
Comment 4 Chris Kühl 2011-06-13 23:40:40 UTC
Thanks for the patch but making these changes causes the processor count to be doubled. Probably related to the changes made in the earlier fix in Bug #619733. Could you update this so I can apply it?
Comment 5 Luciano Chavez 2011-06-14 01:34:10 UTC
Hi Chris,

I appreciate the comments but can you point me to the "processor count" that is getting doubled? I suspect you may not have a ppc64 system so is this doubling side-effect happening on all architectures? I'll set up something this week to apply both patches and see if I can see what you see. Thanks!
Comment 6 Chris Kühl 2011-06-14 07:08:21 UTC
Yes, sorry. There are now 2 entries for each processor core under "Hardware" in the "System" tab. I should normally have 4 logical processors but was shown 8.
Comment 7 Luciano Chavez 2011-06-17 00:16:24 UTC
Hi Chris,

Which version of gnome-system-monitor are you seeing the doubling of the cpu count? I grabbed the system-gnome-monitor-2.28.0 tar.gz source as before, applied both patches and built that and it seemed fine. I don't have an environment to build the gnome-system-monitor 3.x version but can you confirm that the problem is or isn't there with 2.28.0 before I set that up please? Thanks.
Comment 8 Chris Kühl 2011-06-17 09:01:35 UTC
Yes, this is showing up when applied to master. It's only an issue in combination with commit 3ef0ed45 I'd assume.
Comment 9 Luciano Chavez 2011-06-17 14:29:58 UTC
OK. So that would be the 3.1.x development tree I presume. I will try and install something like Fedora 15 to get a more recent environment then that I can build from the latest tree to see if I can see the same issue. Thanks.
Comment 10 Luciano Chavez 2011-06-21 16:51:47 UTC
Created attachment 190380 [details] [review]
Updated patch

Hi Chris,

I installed Fedora 15 on a x86_64 test system with all the supporting -devel packages for building gnome-system-monitor. I also downloaded the latest gnome-system-monitor-3.1.2.tar.bz2 source from June 14, unpacked it and compiled it with the patch and was not able to reproduce the problem. 

I did have to make one minor update to the patch to allow it to apply cleanly since the fix in bug 619733 was already present in the latest gnome-system-monitor source.

I have attached the update to the patch and obsoleted the previous one. If you can apply this patch once more to your source tree and see if you still have the same issue I would appreciate it. If you do, I will need to know more details about your system and environment to properly attempt to reproduce it again.
Comment 11 Chris Kühl 2011-07-02 07:13:28 UTC
Thanks. That seems to work. See commit 401d84dc4.

btw, it's generally easier for us to work with git diffs.
Comment 12 Luciano Chavez 2011-07-05 16:52:05 UTC
Thanks Chris! I will remember the git diffs thing as well for any future submissions.