Created attachment 788212 [details] Screenshot showing negative per-process cpu and invalid cpu% values Description of problem: I've noticed pmatop in current PCP is reporting strangely in a couple of ways: - incorrectly sorting top cpu burners. this might be a 64bit metric issue, where the metric is being displayed using 32bits worth? (attached pcp archive shows this) - some columns are displayed with negative values (attached screenshot shows this) - some columns are displayed with both scientific notation and with K suffix (see screenshot attached) - column widths for some columns overflows the allotted screen real-estate (attached archive shows the problem) Version-Release number of selected component (if applicable): pcp dev branch exhibits the problem. How reproducible: Every time for me, not so much for scox & fche after chatting. May be related to long running cpu-burning processes I have locally. An archive is attached showing the incorrect sorting. Steps to Reproduce: 1. Run pmatop -h local: 2. Run pmatop -r atop 1 3. Both the above show the issues for me Actual results: pmatop displays either the wrong top-cpu-burners (case 2), or sometimes non-existent processes (seen in case 1 occassionally). Expected results: pmatop displays top cpu burners that match up with what top(1) shows. Additional info:
Created attachment 788213 [details] PCP archive showing issues in pmatop output
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Oops, reassign back - pkgdb UI interpretation failure on my part. ;)
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
I think the change "pmatop: use utime/stime instead of schedstat" will fix this. utime/stime units are smaller, milliseconds, and a "try_magnitude" display feature was added to try and use larger display units if possible
pcp-3.8.6-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/pcp-3.8.6-1.fc20
pcp-3.8.6-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/pcp-3.8.6-1.fc19
pcp-3.8.6-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/pcp-3.8.6-1.fc18
pcp-3.8.6-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/pcp-3.8.6-1.el6
pcp-3.8.6-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pcp-3.8.6-1.el5
Package pcp-3.8.6-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pcp-3.8.6-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20460/pcp-3.8.6-1.fc20 then log in and leave karma (feedback).
pcp-3.8.6-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.8.6-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.8.6-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.8.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.8.6-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.