Created attachment 1258467 [details] GNOME Power shows UPower error Description of problem: Since the upgrade to kernel 4.9.11-200 on Fedora 25, running gnome-power-statistics causes upowerd to go wild and consume a lot of CPU and memory resources. This seems to be due to a missing /proc/timer_stats. The situation is exactly the same as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298. Version-Release number of selected component (if applicable): kernel 4.9.11-200, 4.9.12-200 upower 0.99.4-2 How reproducible: Always Steps to Reproduce: 1. Run one of the aforementioned kernels. 2. Run gnome-power-statistics Actual results: gnome-power-statistics hangs and upowerd consumes a lot of CPU resources. Memory usage keeps going up. Expected results: This should not happen. If upowerd is searching in vain for /proc/timer_stats, it should not do so after it fails to find it. Additional info:
Created attachment 1258468 [details] GNOME System Monitor showing resource usage
Created attachment 1258469 [details] GNOME System Monitor showing upowerd CPU usage
The exact situation is as posted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298#40. With kernel 4.8.6-300 /proc/timer_stats is present and this problem does not occur.
Created attachment 1260256 [details] GNOME Power shows UPower error There is no /proc/timer_stats
I've created upstream bug reports: upower: https://bugs.freedesktop.org/show_bug.cgi?id=100626 explaining why /proc/timer_stats is gone gnome-power-manager/gnome-power-statistics: https://bugzilla.gnome.org/show_bug.cgi?id=781088
I can't believe this bug existed as far back to 2012 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689298
This happened to me on Fedora 25 using *KDE*, i.e. not Gnome System Monitor or gnome-power-statistics. I did run all 93 KDE system setting modules (`kcmshell5 --list`) to investigate another bug, and that includes various power management monitors like kcm_energyinfo and powerdevilprofilesconfig. Around the same time upowerd started consuming 30-50% CPU, and `journalctl -xu upower` had 3000 lines like May 26 13:35:34 xx upowerd[1266]: failed to get data: Failed to open file '/proc/timer_stats': No such file or directory Workaround: `systemctl restart upower`
The above workaround does not fix anything for me. GNOME Power still shows UPower error. GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats with gnome-power-statistics hanging and the following software consuming large amounts of CPU resources: upowerd (around 30%), dbus-daemon (around 16%) and gnome-power-statistics (around 14%). There is no /proc/timer_stats.
(In reply to Daibhidh from comment #8) > The above workaround does not fix anything for me. GNOME Power still shows > UPower error. > > GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats > > with gnome-power-statistics hanging and the following software consuming > large amounts of CPU resources: upowerd (around 30%), dbus-daemon (around > 16%) and gnome-power-statistics (around 14%). > > There is no /proc/timer_stats. O.K., "systemctl restart upower" is to fix the ensuing upowerd problem. I just optimistically jumped to the wrong conclusion - that it would fix the gnome-power-statistics problem (silly me!) - until I got my brain into gear, and then hopefully the right conclusion :-). I'm surprised hardly anyone else has added to these reports - does no-one use gnome-power-statistics nowadays?
(In reply to Daibhidh from comment #9) > I'm surprised hardly anyone else has added to these reports - does no-one use > gnome-power-statistics nowadays? I don't think so. It's not a day-to-day end user application. If it is being used, then just once (where it fails) and then users forget about it. Except for the few users who do report bugs.
it does it
sorry... it also affects f26 mate
(In reply to Christian Stadelmann from comment #10) > (In reply to Daibhidh from comment #9) > > I'm surprised hardly anyone else has added to these reports - does no-one use > > gnome-power-statistics nowadays? > > I don't think so. It's not a day-to-day end user application. If it is being > used, then just once (where it fails) and then users forget about it. Except > for the few users who do report bugs. That may be so, but KDE has much more useful information on power usage than GNOME Power. KInfocentre - Energy Information shows which programs are using how much battery power, and that is both extremely useful for laptops and other mobile devices - if the battery starts getting drained, I can see at a glance what is causing the problem, and, to my knowledge the only set-up that provides this information in a user-friendly way as is. Although it does not go haywire like GNOME Power without /proc/timer_stats and appears to deal with the situation more resiliently (on my system upowerd subsequently takes up not more than 1% CPU, and all cores and memory function normally without anything going out of hand), it is still unable to show this energy usage information. This information is one of the several things that set KDE apart with respect to the user having knowledge of what's going on in the system. From the link in comment #5 I gather that /proc/timer_stats has always been optional, but given that practically everything depends on it in the current state of things, I think that it would be more difficult to reprogram all the existing user-end infrastructure than it would be to restore timer_stats, at least until developers of the former are given some time to rewire their stuff. It's just my personal opinion, but I think that API/ABI changes should be introduced gradually and with some grace period allowed to downstream developers.
I also see this problem using gnome-power-statistics in F25. upowerd uses 100% cpu after gnome-power-statistics is run a second or third time, and switching to the 'Processor' tab. Its shows: Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats 'systemctl status upower' shows: upowerd[11778]: failed to get data: Failed to open file '/proc/timer_stats': No such file or directory I have to force close gnome-power-statistics, and run 'systemctl restart upower' to get back to normal cpu usage. Running gnome-power-statistics and switching to 'Processor' tab causes the same problem again. Ok, this was supposedly fixed on 2017-04-23 in https://bugs.freedesktop.org/show_bug.cgi?id=100626 upower relies on /proc/timer_stats, which was always optional and has been removed from recent kernels; busy loop and memory leak https://cgit.freedesktop.org/upower/commit/?id=798588a480eaae50368bed75fc78f8314523b2a3 Do not spin in a loop when /proc/timer_stats cannot be written Can this fix please be pushed out to F25 and F26. Thanks.
upower-0.99.5-1.fc25 has been pushed to F25 testing repo, and it fixes the 100% cpu issue. Cpu used by upowerd is now almost zero. Thanks!! But when running gnome-power-statistics and switching to the 'Processor' tab, it still shows: Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats and no information is listed down the 'Wakeups' page. However, I assume that is now a gnome-power-statistics problem/bug, where gnome-power-statistics needs to now find the info from somewhere else??
with upower-0.99.5-1.fc26.x86_64, I still see upower trying to kill my processor, if I start mate-power-statistics Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type Jul 26 12:29:47 localhost journal: failed to get data: L'ouverture du fichier « /proc/timer_stats » a échoué : Aucun fichier ou dossier de ce type [etc. 1'000'000 lines]
Just to confirm that, for me, following the upgrade to upower-0.99.5-1.fc26, when running gnome-power-statistics and switching to the 'Processor' tab, the upowerd, dbus-daemon and gnome-power-statistics processes do not run away any more, so there is no more high CPU and memory consumption. Thank you for fixing that :-). And also to confirm that when running gnome-power-statistics and switching to the 'Processor' tab, it still shows, of course: Processor wakeups per second: GDbus.Error:org.freedesktop.UPower.GeneralError: cannot enable timerstats and no information is listed on the Wakeups page.
I think that the "cannot enable timerstats"/failure to get data part will remain because it seems to read from /proc/timer_stats. Now, however, even Ubuntu (17.10) seems to have dropped timer_stats, so that the energy information previously available in KDE is also gone, although KInfocentre still doesn't show an error message as GNOME Power does - see comment #13.
(In reply to Heldwin from comment #12) > sorry... it also affects f26 mate Same here, mate-power-manager-1.18.0-2.fc26.x86_64 Shall I open a separate bug against mate-power-manager for using an obsolete API? Is there a replacement they can use?
(In reply to Dominik 'Rathann' Mierzejewski from comment #19) > (In reply to Heldwin from comment #12) > > sorry... it also affects f26 mate > > Same here, > mate-power-manager-1.18.0-2.fc26.x86_64 > > Shall I open a separate bug against mate-power-manager for using an obsolete > API? Is there a replacement they can use? Yes, please report a bug against mate-power-manager. You might want to report it upstream so that other Linux distributions will also get the fixes. As far as I know there is no replacement. The original feature has been removed from the kernel for security reasons and will not be added back again. See comment #5 for details.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.