Version: 4.0.0 (using KDE 4.0.0) Installed from: Ubuntu Packages knotify4 still needs huge number of wakeups/second, causing lower battery life for notebooks. On my idle system, it constantly uses around 88 wakeups/sec. Most of other processes on my system uses below 10 wakeups/second and only couple of HW related stuff interrupts and Xorg use around 15 wakeups/second. I know that this have been improved in past (bug 151832 and bug 151546), but I am not sure if this is new regression than introduced somewhere before 4.0.0 release. HW: HP nw8240 with ATI FireGL V5000 (using FOSS ati drivers) SW: Ubuntu Hardy (up-to-date) with Kubuntu KDE 4.0.0 packages (running also firefox and KDE3 PIM & Konversation when testing)
at two different notebooks (running ubuntu) I could observe over 800 (!) wakeups / sec constantly. HW: Dell Inspiron 9400 with Nvidia 7900 GS using proprietary drivers SW: Ubuntu Gutsy (up-to-date) with KDE 4.0.1 (running nothing else when testing)
Cn Verweildauer P-States (Frequenzen) C0 (Prozessor läuft) (16,1%) 2,00 GHz 2,4% C1 0,0ms ( 0,0%) 1,67 GHz 0,0% C2 0,5ms ( 9,5%) 1333 MHz 0,0% C3 0,6ms (74,5%) 1000 MHz 97,6% Aufwachen pro Sekunde : 1338,7 Intervall: 10,0s Keine ACPI Stromverbrauch-Schätzung verfügbar Häufigste Ursachen für das Aufwachen: 50,7% (896,2) knotify4 : do_nanosleep (hrtimer_wakeup) 36,2% (640,6) <interrupt> : extra timer interrupt 3,5% ( 62,1) <interrupt> : nvidia 2,9% ( 50,8) kwin : schedule_timeout (process_timeout) 2,1% ( 37,8) Xorg : do_setitimer (it_real_fn) 1,5% ( 27,2) <interrupt> : uhci_hcd:usb3 0,6% ( 10,8) S20powernowd : queue_delayed_work_on (delayed_work_timer_fn) 0,4% ( 7,7) <interrupt> : libata 0,4% ( 6,4) konqueror : schedule_timeout (process_timeout)
Same here, knotify takes 90% cpu power even if the system is completely idle. Moreover, whenever a system event causes playing a sound for the irst time, the complete desktop freezes for around a minute. I am using KDE 4.0.1 on openSuse 10.3 on a brandnew computer (NVIDIA 8400, Intel T7250)
I confirm this is on Kubuntu 8.04 with KDE 4.0.3 packages Top causes for wakeups: 18,2% ( 89,3) knotify4 : schedule_timeout (process_timeout) 12,4% ( 60,8) <interrupt> : uhci_hcd:usb3, yenta, nvidia 11,5% ( 56,4) <interrupt> : PS/2 keyboard/mouse/touchpad 10,8% ( 52,9) plasma : schedule_timeout (process_timeout) When Knotify amounts for about a fifth of the CPU wakeups there is considerable battery-time to be saved.
Me too, I have a high wakeup count for knotify4. If I disable sound notifications then the count goes down to less than 1 wakeup per second. This is still happening in today's trunk.
Same here, excepted that it is exactly 78 wakeups/sec for knotify4. (svn trunk from yesterday). Same behaviour than Luis: turning off system sound notifications, then logging out/in (in order to restart knotify4 properly) makes the wakeups disappear. Just in case that is relevant, sound card is an Intel HDA. Maybe it's a driver bug and not a KDE related one ?
"Just in case that is relevant, sound card is an Intel HDA. Maybe it's a driver bug and not a KDE related one ?" I don't think the problem is the driver because I have a completely different graphics setup (M2A-VM motherboard with on-board ATI Radeon X1250-based graphics) and the exact same thing is happening to me. With powertop I was getting around 100 wakeups/second. After turning off the sound notifications and logging out/in the wakeups dropped to around 10 wakeups/second and the memory usage dropped by 20 MB.
I can confirm this. I did a little digging to try and find the cause of the problem. The problem seems to be the 'null' video output plugin in xine causing frequent timeouts when playing media through Phonon with no connected video outputs. Matthew, why is the 'null' xine driver used as opposed to no video driver at all when playing media with no connected video output?
Confirmed on Kubuntu 8.04 with KDE 4.1 beta 1 and linux 2.6.25, snd-hda-Intel.
C2 5,4ms (93,7%) 56,1% (101,9) knotify4 : schedule_timeout (process_timeout)
And disabling the notifications does not work for me. killall knotify4 does, though. ;)
maybe the same bug? #162286
*** Bug 162286 has been marked as a duplicate of this bug. ***
See http://www.kde-apps.org/content/show.php/Phonon+Xine+TNG?content=84411 for a fix.
*** Bug 165971 has been marked as a duplicate of this bug. ***
*** Bug 165901 has been marked as a duplicate of this bug. ***
fixed in trunk (for KDE 4.2)
I thought this had already been fixed in kde 4.0? how was that done? or does suse already use the new backend in 4.0?
Suse applied a patch against the 4.0 phonon-xine package. That patch did get the wakeups down but also introduced new race conditions => crashes. AFAIK the the latest Suse packages don't ship that patch anymore.
I'm using KDE4.1 packages in suse, so i have it okay :)
Is it going to be backported for KDE 4.1.2 ? I'm still getting a lot of wakeups on KDE 4.1.1
As far as I understood Sebastian, the fix is non-trivial and part of a rewrite of the backend, which will (most probably) not be back-ported. But it's part of 4.2, which shouldn't take *too* long.
If you do not want your system be hammered with these 88 wakeups, but still want to have KDE's notification sounds, you can use this workaround: - Go to System Settins->Notifications->Player Settings - Check "Use an external player" - Set "/usr/bin/ogg123" as Player
Comment #14 still applies. Get phonon-xine-tng for all the feedback I got (none) it's working as stable as phonon-xine shipping with 4.1.
*** Bug 171455 has been marked as a duplicate of this bug. ***
This is still happening in 4.3 svn. Switching to the gstreamer backend seems to stop the power hogging, so it is definitely xine's fault.
Trever, do you have knotify trunk, too? On my laptop it shows up with 0.4% ( 3.0) knotify4 : schedule_timeout (process_timeout) in powertop. Please provide more details, so that I can see what is triggering the bug on your system.
Yes, I do. I'm also using xine 1.1.15 powertop output: 55.3% (898.4) knotify4 : __mod_timer (process_timeout)
for me (using KDE 4.2 Beta 2) powertop also shows many wakeups by knotify when the system is totally idle otherwise: Top causes for wakeups: 63.3% (102.7) knotify4 : schedule_timeout (process_timeout) 14.1% ( 22.9) <interrupt> : acpi 6.1% ( 9.9) <interrupt> : ipw2200 using knotify-4.1.85, phonon-4.2.80 from gentoo kde-testing overlay and xine-1.1.15. Switching to no audio output in systemsettings does not seem to make any difference...
actually i have to correct myself: after switching to no audio output and then *relogging in*, knotify does no longer wake up - just as it should be. (but of course i'm having no sound effects anymore)
When powertop shows a high value execute "qdbus org.kde.knotify" and let me know how many /AudioOutputs/* you see.
# qdbus org.kde.knotify |grep AudioOutputs /AudioOutputs /AudioOutputs/0 out of couriosity i triggered many events that cause sound effects and looked again while playing there are more AudioOutputs (of course) and the wakeups go up accordingly. But when all sounds finish I have: # qdbus org.kde.knotify |grep AudioOutputs /AudioOutputs /AudioOutputs/14 So still one open causing the wakeups?
Still one open is the correct behavior. But it shouldn't cause that many wakeups. I'd expect numbers like yours when it has ~40 outputs open.
Hmm, there's only one reason I can think of that you get those high numbers: you're using an older phonon-xine backend. (perhaps you have phonon-xine-tng installed and configured to be used?)
hm, strange - i have no other plasma backends installed. only (the gentoo kde-testing overlay packages): kde-base/phonon-kde-4.1.85 media-sound/phonon-4.2.80 Maybe a interesting side note: The systemsettings phonon configuration does not show any backends for me. And i had the problem that phonon always used the gstreamer backend (which didn't work for me).(actually some other gentoo users in irc had the same problem). So i rebuild the gentoo packages without gstreamer. Now phonon has no other choice than to use the xine backend. (But still no backend shown in systemsettings). So i am pretty sure it uses the xine backend of media-sound/phonon-4.2.80). Only file that # find -name phonon_xine.so brings up is: /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so
Oh, now I see. The necessary fix didn't reach the 4.2.80 tag. You need to compile phonon trunk to see the wakeups go down.
updated to trunk really helped. (sorry for making noise about it - thought the fix was already in kde4 beta2).
Hey, the fix *will* go into 4.2, though, right? It really should I think.
*** Bug 179975 has been marked as a duplicate of this bug. ***
I'm still seeing this with 4.2 final, phonon and xine-backend 4.3.0. What can I do to troubleshoot it further? 73.8% (990.9) amarok : futex_wait (hrtimer_wakeup)
It's been a long time since I've seen 1000 wakeups/s with xine. I fixed that for libxine 1.1.14 or such... When xine is polling for data internally you should see ~90 wakeups/s per media stream. That part is normal, though fixable in libxine with a more invasive change how data is exchanged between its threads. If playback is stopped the wakeups stay like they are, unless the MediaObject is deleted or its currentSource is set to MediaSource::Empty. The latter is what knotify uses in KDE 4.2 to get rid of the wakeups. Please check if knotify behaves. Please check if other xine based applications have the same wakeup numbers.
The issue seems to be caused by: http://bugs.kde.org/show_bug.cgi?id=156215#c8 as playing video with sound will create acceptable less then 100 wakeups/second (very noticable on dragon) A quick check with reactivating sound notifications for knotify4 looks like it is behaving with actually stopping all the wakeups after it played it's tune, but I wouldn't consider this thorough testing
Karsten: about comment #8: it's a libxine limitation that phonon-xine has to use the "none" video output instead of none at all. It might be fixable in libxine, and I'd be very happy for a fix, but it's out of scope for this bug report. > as playing video with sound will create acceptable less then 100 wakeups/second > (very noticable on dragon) I don't understand what you're trying to say with this. Thanks for confirming that knotify behaves...
> > as playing video with sound will create acceptable less then 100 wakeups/second > > (very noticable on dragon) > > I don't understand what you're trying to say with this. Playing a video&audio file, aka movie =), will result in less then 100 wakeups/second, only playing audio files creates ~900 wakeups/second So I thought it might be related to using the "none" videooutput > Thanks for confirming that knotify behaves... knotify also creates the many wakeups when playing a sound notification, but now stops after the sound is done, so this is fixed yes =) The many wakeups/second are also reproducibly in systemsettings when testing the audio files for notifications
Ah interesting. I don't see that behaviour. For me it shows ~90 wakeups/s regardless of whether it's playing with a VideoWidget, without, with video stream or without.
It is not only ubuntu problem. I installed OpenSuSe 11.1 on my HP Pavilion dv5 (AMD Athlon X2) laptop and knotify4 uses 100% CPU without any activity.
*** Bug 191466 has been marked as a duplicate of this bug. ***
Still an issue with 4.3 beta 2 (on SUSE 11.1). Changing the backend to GStreamer and rebooting works: knotify completely disappears in the powertop's list.
I said the wrong version, I have 4.2.4, not 4.3 beta 2.
i have kde 4.3.1 and knotify4 with high cpu usage. Is is the same bug or i have to open another report ? %CPU 2806 dimitris 20 0 245m 42m 14m S 84.6 3.3 8:17.44 knotify4 2381 dimitris 20 0 273m 40m 22m S 5.3 3.2 1:53.79 kwin 2804 dimitris 20 0 373m 108m 40m S 2.7 8.6 1:12.68 plasma-desktop 941 root 20 0 372m 226m 8152 S 2.0 17.9 5:23.11 X 11344 dimitris 20 0 110m 34m 16m S 1.0 2.7 0:00.65 konsole 2986 dimitris 20 0 419m 48m 17m S 0.3 3.8 0:07.69 nepomukservices
Is this still an issue?
Closing for lack of feedback. Most likely already fixed.
It is not an issue to me anymore, because I'm not using kde4 due to a lot of problems and lack of functions. I'm working on kde3 :-(
*** Bug 168441 has been marked as a duplicate of this bug. ***
Same issue on Kubuntu Karmic with amarok and KDE 4.3, and still here on KDE 4.4 RC2. Killing knotify4 solves the problem short term. At now, for example, Knotify uses every time 99-100% one of my 3 AMD processors every time, total is 64 hours of CPU usage: $ ps u -p 29200 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tat 29200 0.9 0.3 713364 13064 ? SNl Jan26 64:41 /usr/bin/knotify4 Can I give you more debug info for detecting the problem?
Reopening...
Setting version
same here with kde 4.4.2 on latest archlinux workaround: http://bbs.archlinux.org/viewtopic.php?id=77531
Yes, this is reproducible on Gentoo. All of a sudden it will start using 100% CPU (as it happed this night during the emerge process as a result emerge was still running by the morning). Other symptoms include the notification towards the lower right opens up saying "no jobs running" during a copy paste operation. All these happen some times by that copy paste problem is very often and I think they are related.
I also have this problem on ubuntu 10.10. it was immediately gone when switching to the vlc phonon backend.
*** Bug 185265 has been marked as a duplicate of this bug. ***
Have/had this 2. Installed kubuntu 11.04 yesterday and just had knotify4 and kded4 taking an absurd amount of cpu cycles for no apparent reason. I switched to ati fglrx today and because of that the workaround from http://bbs.archlinux.org/viewtopic.php?id=77531 didn't work. I disabled fglrx and it is good for now.
I've also encountered this problem of knotify4 high CPU usage: opensuse 11.4 64 bit, KDE 4.5.2 from KDE factory repository. I'm not sure whether I had the issue with 4.5.0 or not, but certainly do now: on a quad core knotify4 can sometimes take 25% of CPU (one full core I assume) until killed. If I kill knotify4 from System Monitor then relaunch from the konsole I get a system notification (delayed reporting of connection/disconnection of my USB headset), then knotify4 is happily at 0% CPU again. I note a later bug report http://bugs.kde.org/161828 that seems to be the same thing.
Hello, As far as I seen this was fixed [for me at least] in 4.6
It happens only with phonon gstreamer.
Some bugs that were duplicated to this one, are about phonon-gstreamer, not phonon-xine. I personally don't have xine installed at all, use gstreamer phonon backend and also get high cpu usage by knotify4 (it 100% happens after kde login sound, stops if i killall knotify4 and starts again when sounds are played). On 6-core phenom knotify4 uses ~15% cpu, on 400mhz armv6 it uses 100% cpu making system to crawl until i kill knotify4. Disabling sound notifications fixes the issue.
(In reply to comment #66) > Some bugs that were duplicated to this one, are about phonon-gstreamer, not > phonon-xine. > > I personally don't have xine installed at all, use gstreamer phonon backend and > also get high cpu usage by knotify4 (it 100% happens after kde login sound, > stops if i killall knotify4 and starts again when sounds are played). > > On 6-core phenom knotify4 uses ~15% cpu, on 400mhz armv6 it uses 100% cpu > making system to crawl until i kill knotify4. Disabling sound notifications > fixes the issue. I can ensure this does not happen with xine enabled. But when I open any app in root.
dE, that could be caused by a crappy audio setup where playback is blocked by another application of another user (i.e. your user). Anyhow, if you experience this with pgst, then please report a bug for pgst.
Also see https://qa.mandriva.com/show_bug.cgi?id=49814#c32
(In reply to comment #68) > dE, that could be caused by a crappy audio setup where playback is blocked by > another application of another user (i.e. your user). > > Anyhow, if you experience this with pgst, then please report a bug for pgst. That means a sound server should solve the problem.
Still reproduce on KDE 4.7 beta1
(In reply to comment #68) > dE, that could be caused by a crappy audio setup where playback is blocked by > another application of another user (i.e. your user). > > Anyhow, if you experience this with pgst, then please report a bug for pgst. Well, closing all notification sounds did not solve the issue.
kubuntu 11.04. knotify4 wakes up 20 times per second
using phonon-gstreamer-4.5.0 on phonon-4.5.0 and kdelibs-4.7.2 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597372842}) = 0 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597455632}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN}, {fd=5, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout) read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597598563}) = 0 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597659599}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN}, {fd=5, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout) read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597758649}) = 0 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597822391}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN}, {fd=5, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout) read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597925974}) = 0 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 597984967}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN}, {fd=5, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout) read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 598087018}) = 0 read(8, 0x9ad15a0, 4096) = -1 EAGAIN (Resource temporarily unavailable) clock_gettime(CLOCK_MONOTONIC, {565, 598246786}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN}, {fd=5, events=POLLIN}, {fd=16, events=POLLIN}], 6, 49^C <unfinished ...> Process 2690 detached
Got hit by this (knotify4 @ 100% CPU) after playing a bit with my ALSA settings on my box (Gentoo, phonon 4.5.1, phonon-gstreamer-4.5.1, KDE 4.7.3). Removing the 'defaults.pcm.rate_converter' setting from my ~/.asoundrc 'fixed' this (I'm using an X-Fi). qdbus org.kde.knotify was indeed showing an 'extra' /AudioOutputs/1 that I don't see anymore (when idle). On a sidenote, I didn't try the mandriva patches #69 linked to, but they still apply, so that might also be worth looking into.
We are sorry, but the xine backend is unmaintained: http://lists.kde.org/?l=kde-announce&m=130744384419151 Please use the phonon-backend-gstreamer or thre phonon-backend-vlc instead.
In the mean time, this is no longer a problem since 4.6. It's no longer reproducible both on Debian and Gentoo.
And I'm using the xine backend.