GNOME Bugzilla – Bug 468495
System Monitor system tab does not show all CPUs
Last modified: 2011-11-17 06:10:19 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/131295 "Binary package hint: gnome-system-monitor On Dell PowerEdge 1950, dual quad core Xeon only the first 5 CPUs are listed on the gnome-system-monitor system tab. This list should if possible auto-resize to accomodate any number of CPU cores. Also the automatic colour selection for the CPU time graphs on the resources tab uses the same red colour for the last four CPUs. ... http://launchpadlibrarian.net/8746711/system-monitor.png system-monitor.png (43.2 KiB, image/png) Version is 2.18.1.1. Obviously the colour issue on the resources tabs is easily fixed by the user selecting their own colours so is quite trivial. Screen shot attached."
Please attach your /proc/cpuinfo
the submitter reply "http://launchpadlibrarian.net/8910688/cpuinfo.txt Cpuinfo details (3.9 KiB, text/plain) Cpuinfo attached. Fairly straightforward, two quad core L5320 Xeon processors."
If you have gnome-python-desktop, could you please thy this : python -c 'import gtop; print gtop.cpu()'
Which libgtop version ?
ok, i think i found it anyway :)
how many CPU are displayed in the resource tab ?
ok, sorry for all that spam, i'm just working on it. then : python -c 'import gtop; print gtop.sysinfo()'
'http://launchpadlibrarian.net/8915749/python-gtop.txt python-gtop.txt (6.2 KiB, text/plain) Output from python in attached files. Eight CPUs are shown in resources tab but the initial state is for the last four to all have the same colour (red)."
Is that the same kernel ? because some fields are new. I cannot reproduce it myself, i'm running with your cpuinfo and get the 8 CPUs. grep BUFSIZ /usr/include/*.h please ? There's a little bug in gnome-python-desktop/gtop, i'm going to fix, that's why the cpu() lists have only 7 elements. The color issue is a different topic, easy to fix. Just to check, are all the graphs showing activity ?
the same kernel than what? feisty has 2.6.20
the one used to get cpuinfo and the one used to run these python tests
reply from the distribution bug submitter "http://launchpadlibrarian.net/8953673/cpuinfo.txt cpuinfo.txt (4.9 KiB, text/plain) Attached a new cpuinfo file, the desktop machine was unavailable when I generated the cpuinfo.txt so that came from an identical system running Ubuntu 7.04 Server. The python run was performed on the desktop machine that shows the problem. Note, the problem exists only on the "System" tab, i.e. the left most tab that shows the OS version, CPUs and system status. The graphs page shows all 8 cores correctly so it looks like the underlying libraries correctly enumerate things but the UI just doesn't have space to list all the CPUs. I did notice in the output from the python run that it sees them as 2 CPUs each with 4 cores which is is correct. So maybe a better way of listing them would be to list the actual physical CPUs and then have an expander to list the cores for a particular CPU?"
Yes, the grouping/expander looks like a good idea. But /proc/cpuinfo is really fuzzy, there is no standard formatting between arch. And it's linux-centric, but why not :) I'm really waiting for you to post 'grep BUFSIZ /usr/include/*.h', because i don't know why but libgtop heavily relies on this macro for buffer size, and this could explain why the resultat are truncated. Because with these cpuinfo files, i can't reproduce, i get the full list.
the BUFSIZ is set to 8192
*** Bug 502572 has been marked as a duplicate of this bug. ***
I see the same thing under fedora. There is also the fedora bug about it. https://bugzilla.redhat.com/show_bug.cgi?id=467455 Confirming.
Could you please run http://launchpadlibrarian.net/8915749/python-gtop.txt ?
Could you please attach your /proc/stat and tell me what is your libgtop version ? Thanks.
Did you read comment 12 carefully? There should not be a problem with libgtop if the graphs page shows the correct number of cores. Its the "System" tab only that is the problem. Unless of course g-s-m has umpteen ways of determining the same thing....
Created attachment 120875 [details] The requested various output
Well, that's exactly the case in libgtop. That bug was workaround around 2.19.91 that's why i'd like to know your libgtop version.
Paint me confused. libgtop shouldn't have to do anything with the difference between the number of cores reported in the "System" tab and the one in the "Resources" tab in gnome-system-monitor. I was testing both gnome-system-monitor and libgtop from fedora rawhide libgtop2-2.24.0-1.fc10.i386 gnome-system-monitor-2.24.0-3.fc10.i386 and the ones from jhbuilding head.
Created attachment 120884 [details] Combined screenshot, one says 6 the other 8
If you look at the gtop.sysinfo() output, you can see only 6 cores, just like on the screenshot. The first tab uses sysinfo() while the resources tab uses gtop.cpu(). That's why i'm looking into a libgtop problem.
I wonder why when i replay the cpuinfo file you provide with 2.24.0 i get : LD_LIBRARY_PATH=lib/.libs python -c 'import gtop; print [p["processor"] for p in gtop.sysinfo()];' ['0', '1', '2', '3', '4', '5', '6', '7'] :/
Sorry for being so petulantly incredulous. Couldn't believe the libarary had more than one way of fetching that particular info. The problem is indeed a short read of /proc/cpuinfo in init_sysinfo->file_to_buffer from libgtop, here it does only 4050 bytes, it has to be read again to get the whole thing. Perhaps this has something to do with the 4KB fedora kernel stack size. I see you've done a similar workaround in the past for /proc/stat reading.
I've been told this 4K are actually the kernel page size and this is exactly the expected behaviour. These files should be read 4KB a piece.
(In reply to comment #26) > Sorry for being so petulantly incredulous. Couldn't believe the libarary had > more than one way of fetching that particular info. It's not the same info at all. On one hand you have the cpu features, on the other hand you have the cpu times. It's the parsing that fails in one case. > The problem is indeed a short read of /proc/cpuinfo in > init_sysinfo->file_to_buffer from libgtop, here it does only 4050 bytes, it has > to be read again to get the whole thing. Perhaps this has something to do with > the 4KB fedora kernel stack size. I see you've done a similar workaround in the > past for /proc/stat reading. Any strace of "python -c 'import gtop; print [p["processor"] for p in gtop.sysinfo()];'" ? That's not related at all to kernel page size.
I told you what happens because I've tracked and tested it. You need to read the proc files (in this case /proc/cpuinfo) in less than page size pieces or in whatever pieces the OS gives it to you, but with more than one read. I doesn't have anything to do with wrong parsing of the output.
I don't care then. "works here".
Created attachment 120997 [details] [review] minimal fix to libgtop. works for me.
The patch leaks buffer
Created attachment 126219 [details] [review] read file into buffer completely read should be looped until it returns 0 or the buffer is full. This patch works for me as I can reproduce the same bug.
i know, i just don't get why this could be interrupted. i'd just like someone to show me a strace output
Want the whole strace file or just the relelvant lines? Here is what looks to be the relevant snippet... 7222 stat("/usr/bin/lsb_release", {st_mode=S_IFREG|0755, st_size=10750, ...}) = 0 7222 open("/proc/cpuinfo", O_RDONLY) = 17 7222 read(17, "processor\t: 0\nvendor_id\t: Genuin"..., 16383) = 3660 7222 close(17) = 0 7222 open("/proc/meminfo", O_RDONLY) = 17 7222 read(17, "MemTotal: 6118460 kB\nMemFre"..., 8191) = 826 7222 close(17) = 0 7222 open("/etc/mtab", O_RDONLY) = 17 7222 futex(0x7f694f882b80, 0x81 /* FUTEX_??? */, 2147483647) = 0 7222 fstat(17, {st_mode=S_IFREG|0644, st_size=829, ...}) = 0 7222 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6953644000 7222 read(17, "/dev/sda5 / ext3 rw,relatime,err"..., 4096) = 829 7222 open("/proc/filesystems", O_RDONLY) = 18 7222 fstat(18, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 7222 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f69534e9000 7222 read(18, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 1024) = 309 7222 read(18, "", 1024) = 0 7222 close(18) = 0
OK thanks. I found it very strange because even when i run libgtop on a 128 way ia64, i don't get this behaviour, the content on /proc files always comes as a whole.
I've commited a patch a bit different, i hope you won't mind. http://svn.gnome.org/viewvc/libgtop/branches/gnome-2-24/sysdeps/linux/glibtop_private.c?r1=2790&r2=2789&pathrev=2790
If the patch for this has been commited, and fixes the problem, this issue should be set to Fixed.
As the fix is in libgtop master([1]), I am setting this as fixed. Feel free to reopen if you have this issue using gnome system monitor 3.2.1 or later. [1] http://git.gnome.org/browse/libgtop/tree/sysdeps/linux/glibtop_private.c#n70