143255 2007-03-20 13:53:57 +0000 Superkaramba makes X.org unresponsible 2009-07-16 23:49:20 +0000 1 1 10 Unmaintained superkaramba general unspecified Gentoo Packages Linux RESOLVED WONTFIX NOR normal --- 1 kejpi p0z3r alessandrosturniolo clark jacopods+kde jaguarwan l.lunak mikebwilliams nick ppeltz 301 oldest_to_newest 516279 0 kejpi 2007-03-20 13:53:57 +0000 Version: 3.5.6 (using KDE KDE 3.5.6) Installed from: Gentoo Packages Compiler: gcc 4.1.1 OS: Linux When KDE is running in idle (without any user actions) and superkaramba is running then after some time CPU occupation increases. CPU occupation comes to normal if I start using KDE again. Looking at top list I can see that it is X CPU occupation (not superkaramba). If I let KDE in idle for a long time (2 hours) X becomes unresponsible and usually even Ctrl+Alt+Backspace doesn't help and I have to reset computer. I am using X.org 7.1.1. I did some observations and here is the result: 1) The problem was not present in KDE 3.5.5 2) When superkaramba is not running the problem is not present 3) If only one superkaramba applet is running the problem is not present 4) I have tried to download and compile superkaramba 0.39 from superkaramba home page but the behaviour is the same 5) killall superkaramba and starting new instance doesn't help. 6) Working on computer whole day the problem doesn't occur - it only occurs when KDE is not used (in idle) 517738 1 ppeltz 2007-03-28 17:42:36 +0000 I'm having the same problem and can reproduce this behavior. 525324 2 krisztian.t 2007-05-11 14:14:35 +0000 I can confirm this bug too on my Kubuntu Feisty (Kubuntu 7.04) KDE: 3.5.6 Here's the Ubuntu bug report about this problem: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/109507 525330 3 ppeltz 2007-05-11 14:58:38 +0000 Can you vote for this bug then please? Unless it gets more votes it won't be confirmed. Thanks. 525540 4 krisztian.t 2007-05-13 07:33:43 +0000 *** This bug has been confirmed by popular vote. *** 525541 5 krisztian.t 2007-05-13 07:36:36 +0000 Thank you for reminding me! I forgot to vote. Now I did it. 530540 6 footer 2007-06-08 14:02:26 +0000 I voted for this bug. I have two Superkaramba applets running on my desktop (Kubuntu Feisty Fawn 7.04, KDE 3.5.6). My desktop freezes after sitting idle for awhile but only for 20-30 seconds after which I can use it again. Very ANNOYING problem! Thanks! 531723 7 geekbanter 2007-06-15 21:52:45 +0000 Same problem here on PCLinuxOS 2007. Problem initially started when leaving the desktop locked overnight and in the morning the computer was unresponsive. It took a while to narrow my problem down to superkaramba in general, and not a specific applet. It seems like the more applets running the more severe the problem. No superkaramba, all is fine idling overnight. Three simple applets (clock,tmon,wifi) and desktop is sluggish or unresponsive for a minute after idling for several hours (CPU=100% for X). Five applets (add liquid weather and gsm) after a several hour lock and on a few overnight occasions X will not respond beyond showing the password dialog. Trying to kill X (Ctrl+Alt+Bksp) will lock the system As mentioned by others the problem does not exist while the computer is being used, even all day long. CPU: AMD64 3000+ MB: A8N-SLI Premium VGA: Nvidia Geforce 7600GT w/Nvidia 97xx drivers Xorg: 7.0.1 KDE: 3.5.6 531839 8 kejpi 2007-06-16 16:04:45 +0000 Seems to me that the problem is not present in KDE 3.5.7. Could anybody else confirm it? 531987 9 markaki2002 2007-06-17 13:06:18 +0000 Same Problem here on Gentoo linux with KDE 3.5.7 and superkaramba 532001 10 footer 2007-06-17 15:24:16 +0000 I still have the problem with KDE 3.5.7. I've only had it installed for about 24 hours but it's happened to me once already (though it was only about a 20 second freeze so maybe it's improved?). Unfortunately, KDE 3.5.7 seems to have brought on another bug, the dreaded "Received signal 15, shutting down cleanly" bug referenced here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94862 I have not had this bug in awhile and KDE 3.5.7 is the only upgrade recently so not sure what's going on. ARGH! 542542 11 wirr01 2007-08-25 00:26:18 +0000 You all report that this happens when your computer is idling, so I assume that you use a screensaver for now. A bug was already posted about a similar problem: https://bugs.launchpad.net/ubuntu/+source/kdeutils/+bug/94345 It is possible that this behaviour of xscreensaver makes X unresponsive. So I would like to check this out first. So please tell me if you use a screensaver or xcreensaver and what happens when you don't use one at all? Besides that I currently have no other idea, but I'll try to investigate further. Thanks! 542544 12 footer 2007-08-25 00:31:22 +0000 Sorry, no screen saver here. Just power saving monitor feature after 10 minutes (Kubuntu Feisty Fawn 7.04). 542549 13 geekbanter 2007-08-25 01:50:39 +0000 I don't use superkaramba anymore because of this problem. Back when I was having the problem I didn't use a screensaver, but I also had the monitor go to sleep after about 15 minutes. (PCLinuxOS 2007 - KDE 3.5.7) 542566 14 technowizard 2007-08-25 09:53:33 +0000 No screensaver, no power saving feature. But got the same problem again yesterday after activating a second theme. 542589 15 footer 2007-08-25 13:53:02 +0000 I forgot to point out that from the original post: 3) If only one superkaramba applet is running the problem is not present This has been my experience as well. If I leave just one applet running, I don't experience this problem. 542698 16 eugene 2007-08-26 09:09:49 +0000 I have the same situation on 2 my computers (desktop and laptop). I stopped using superkaramba and the issue disappeared. 544154 17 dd 2007-09-02 21:12:39 +0000 Confirming presence of behavior on OpenSuse 10.2 + some updates. X v7.1.99.902 SK 0.42 KDE 3.5.7 Intel 810/815 chipset / video adapter, non-proprietary, pure Xorg driver. Compositing enabled. Screensaver enabled with "blank screen" mode. Was running "Translate Plus", "Desktop Basket", "Horovod", the new (SVN) version of Kaddressbook theme. After 5 hours of inactivity, Xorg thread was using 70-100% of CPU (according to top) and did not respond to clicks on any of the widgets. Since X stops responding to CTRL+ALT+F# keypresses, the only way to switch away from "frozen" X to a console was to induce suspend-to-disk and switch (CTRL+ALT+F1) to console right before X is fully re-activated. After switching to console in such a way, I was able to killall superkaramba, all python threads, anything related to superkaramba, yet X showed same 80-100% CPU usage. Killing X, and letting kdm restart it, of course, brings the system to normal. Inspecting the "ps aux" and "top" output during the "100%" behavior and in normal conditions do not show much difference in terms of superkaramba memory consumption. Xorg consumed considerably more memory during "100% CPU" period (92Mb ps aux)(190+Mb top) compared to normal condition (56Mb ps aux)(139Mb top). (Interestingly, "ps aux" does not show Xorg consuming cpu, while top does...) Next, I will try to: 1) turn the screensaver off, 2) turn composite off, 3) run some python-less themes and see if the behavior continues to occur. 544160 18 kejpi 2007-09-02 21:24:48 +0000 It is strange that the bug disappeared on my system after upgrading to KDE 3.5.7 while on others it is still present. I don't know what else changed on my system. 544215 19 dd 2007-09-03 07:32:12 +0000 Continuing troubleshooting: Specs again: X v7.1.99.902 SK 0.42 KDE 3.5.7 Intel 810/815 chipset / video adapter non-proprietary, pure Xorg driver for intel81x As promised previously, tested the following 3 configurations: Level 1. Switched to python-less themes Level 2. Turned off screen-saver completely, Level 3. Turned off "Composite" extension. Everything else the same + level 1 = this bug still occurs. In fact, using 4 copies of the same monitor theme with 1 second refresh and lots of chart/meters reliably reproduced the bug in 30-40 minutes. Level 1 + 2. Checked, neither xscrensaver, nor kscreensaver is running. Bug is present, with NO change in character. It is NOT caused by the screen saver. Level 1+2+3. COmposite extension OFF. (Both, GLX and DRI extensions stay enabled) Bug DISAPPEARS. Disabling composite extention makes system run normal in idle. The longest I waited is 2 hours. Considering that previously the bug would show up in 30 minutes, this may be our reasonable clue. I will try running on idle in this configuration again, over night, and see if non-composite set up just delays the problem or really alleviates it. Questions to others: - if you experience this problem, what is your video chipset / video driver / composite off/on? 544337 20 kejpi 2007-09-03 20:26:10 +0000 I have GeForce 7600 GS adapter, proprietary NVidia driver is used, and this is the beginning of xdpyinfo. You can see that composite is switched on because I am using compiz-fusion. # xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70200000 X.Org version: 7.2.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x2e00008, revert to PointerRoot number of extensions: 32 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD NV-CONTROL NV-GLX RANDR RENDER SECURITY SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number: 0 number of screens: 1 544338 21 kejpi 2007-09-03 20:28:34 +0000 Sorry I have forgotten to write that I don't have the problem any more even that I use composite extension. The problem disappeared after upgrading to KDE 3.5.7. 544370 22 dd 2007-09-04 01:01:50 +0000 Checked overnight. The bug occurs even with Composite, GLX, DRI, DBE extensions OFF. I thought for a while it's some sort of double-buffering inefficiency, or some other "accelerated" feature problem... No. This has something to do with core X. Either threading issues, or some other unusual, hard-to-catch problem. It is rather hard to imagine how we are going to catch it, and what actually caused this: a change in Xorg, or a change in SK... 545965 23 hitman1 2007-09-14 23:07:55 +0000 I'm experiencing the same problem here with MEPIS 7.0 Beta4 Kde 3.5.7 superkaramba 0.42 I just turned off superkaramba after reading this thread; first idle night without an xorg hang. Lets see how it goes the 2nd night. 552558 24 sgrayban 2007-10-31 03:37:12 +0000 I have the same problem as well. $ kde-config --version Qt: 3.3.8 KDE: 3.5.6 kde-config: 1.0 X: 1.2.0 This is a real shame -- the svn version (.42) works just fine in KDE 3.4 -- its completely broken in KDE 3.5 554569 25 jarod1982 2007-11-10 23:13:43 +0000 Same problem for me too: - Kubuntu Feisty 7.04 - KDE 3.5.7 - ATI Radeon 7500 with open drivers - xorg 7.2 - superkaramba 0.41 I just came to know of the relationship between the problem and superkaramba, still have to try if disabling it "solves" the problem... if disabling one of KDE's coolest features can be called a solution. I'll bring more info in a couple of days of tests. 554690 26 jarod1982 2007-11-11 20:35:14 +0000 Up to now, with SK totally shut off, no occurrances of the problem. Now I'm going to test what happens leaving superkaramba running with only one theme loaded. 555141 27 jarod1982 2007-11-13 22:08:59 +0000 I've been with SK running with only one theme, and still no occurance of the problem. 555176 28 sgrayban 2007-11-14 02:11:56 +0000 X dies when 2 or more SK themes are running. Having only 1 SK theme running does not hurt X at all. 557845 29 ck74 2007-11-25 02:08:11 +0000 Hello! I'm using KDE 3.5.8. on Unix, i can confirnm the problem. If i do not use the computer for about an hour, Xorg starts to use 100% CPU and computer does not response to any command. Regards, 558167 30 ck74 2007-11-26 17:40:49 +0000 Additional information: If only one applet is active, and if computer is idle for about 2 hours, CPU usage stays around 40 ~ 60 % and computer responds keyboard and mouse activities and back to normal. 562093 31 jaguarwan 2007-12-11 09:16:03 +0000 I have this bug too, if I let sit my laptop idle (Core Duo, i945gm intel gpu) Xorg CPU usage will slowly increase to 100% over time. If I close superkaramba the issue disappears. Curiously, simply clicking several times on the desktop or in an open shell window will bring back Xorg CPU consumption to normal quite instantaneously. 564661 32 guitch21 2007-12-19 04:31:53 +0000 Same problem here with Debian Unstable : Qt: 3.3.7 KDE: 3.5.8 kde-config: 1.0 X.Org X Server 1.4.0 NVIDIA proprietary driver 96.43.01, Composite enabled Superkaramba 0.42 The bug appears after about 30 minutes, if I click on the desktop, Xorg CPU consumption sometimes goes back to normal, otherwise, Ctrl-Alt-Backspace. 567144 33 magnus 2007-12-30 11:00:37 +0000 Have the same problem. Solved when SK is shutdown. Kubuntu 7.10 (KDE, SK, QT - all Ubuntu packages) ATI Radeon 9800, ATI driver 8.40.4 Same behavior as Guitch (comment #32) 570455 34 wirr01 2008-01-12 20:33:49 +0000 Can someone please confirm if this still happens with KDE 4.0 or not? 571252 35 jaguarwan 2008-01-14 14:11:51 +0000 I think this bug may be tied to something in kwin, because I tried compiz-fusion this afternoon with the exact same superkaramba widgets I use everyday, and the CPU usage raise did not occur at all. Since the only KDE component that compiz-fusion replace is kwin, I think maybe the bug lies somewhere in there? 571259 36 footer 2008-01-14 14:18:02 +0000 Sorry but I beg to differ. I've been using compiz-fusion for a long time and the same two superkaramba widgets equally as long and if I leave both of them running and come back several hours later, she's froze up! It takes from 30-45 seconds to break free again (thankfully, no hard reset). As long as I leave only one superkaramba widget on the desktop though, no problem. Xorg CPU and memory usage definitely climbs with more than one widget open with compiz-fusion. 586381 37 jaguarwan 2008-03-12 12:32:50 +0000 OK 哥们儿s, I did more testing and here is my results: * The bug does not occur with only one widget (the docker kroller) * The bug still occurs on KDE 3.5.9 with the two widgets (kroller + Borealis) * The bug does not occur with compiz, which lead me to suspect kwin * I tested running the kwin from KDE 3.4.3, since I only remember having this bug since the 3.5.x serie, and the bug does *not* occur anymore with the two widgets active and kwin 3.4.3. => between kwin 3.4.3 and 3.5.x, some change was introduced which triggered this bug. Since it's X that is eating CPU cycles and not kwin, I guess kwin must issue many X calls for some reason without getting stuck in a loop itself. So in my case at least, the window manager is definitely involved. 586414 38 jaguarwan 2008-03-12 15:48:18 +0000 Actually, as the original reporter said, I don't have any problem either using kwin 3.5.5. So the change that cause this bug must be in the changeset between kwin 3.5.5 and 3.5.6. 586504 39 jaguarwan 2008-03-12 23:19:52 +0000 OK, after selectively testing reverting changes to every modified source file between 3.5.5 and 3.5.6, it appears that the changes to layers.cpp caused the bug to appear, but I don't understand why yet. For the most impatient, you can just make a diff between 3.5.6 and 3.5.5 layers.cpp and apply it to 3.5.9,the bug will be fixed. 586507 40 sgrayban 2008-03-12 23:36:46 +0000 Is layers.cpp part of KDE source or SK source ? Would you mind posting a diff for the technically challenged ? 586514 41 jaguarwan 2008-03-13 00:06:20 +0000 layers.cpp is in kwin sourcecode, in the kdebase package. I'm still trying to narrow down the diff to find the real source of the bug, I will post one as soon as I find the offending lines (not just revert to 3.5.5 layers.cpp). 586519 42 sgrayban 2008-03-13 00:10:07 +0000 Ok thanks 586533 43 jaguarwan 2008-03-13 01:16:28 +0000 OK, this diff fixes the bug on my configuration: ----------------------8<-------------------------- --- kdebase-3.5.6/kdebase-3.5.6/kwin/layers.cpp 2007-01-15 12:32:14.000000000 +0100 +++ kdebase-3.5.5/kdebase-3.5.5/kwin/layers.cpp 2006-05-22 20:13:01.000000000 +0200 @@ -117,11 +117,7 @@ } #endif if( changed || propagate_new_clients ) - { propagateClients( propagate_new_clients ); - if( active_client ) - active_client->updateMouseGrab(); - } } /*! ----------------------8<-------------------------- Put it in the kwin source directory and apply with: patch -p3 < whatever_you_name_the_diff.diff Then compile to go back to the sane 3.5.5 behaviour. I checked if this could come from updateMouseGrab(), but apparently some changes made to it from 3.5.5 from 3.5.6 were already reverted. I must confess that I don't know very well how these innocent looking lines trigger the bug, but I would be grateful if you could test this patch for possible regressions and apply it to SVN, so this really annoying bug can be finally solved :) 586603 44 sgrayban 2008-03-13 12:19:49 +0000 That seems to have fixed for me also. KDE no longer hangs on any of my boxes including the 3 different distros I use here, Mandriva, debian and gentoo. Great work jaguarwan for figuring this out. On the side note I have no clue what those lines do and I don't see anything that regressed or even broke from removing those lines out. All my desktops work just fine. All mouse functions work just like they did before so that is a good sign that nothing was broken doing this. I will pass this along to Ryan who is one of the coders for SK so that they are aware of this possible fix and that it isn't SK fault. 586946 45 sgrayban 2008-03-14 18:13:57 +0000 Bug #128648 broke this. 586950 46 sgrayban 2008-03-14 18:33:53 +0000 WebSVN diff http://websvn.kde.org/branches/KDE/3.5/kdebase/kwin/layers.cpp?r1=603048&r2=603293 586952 47 l.lunak 2008-03-14 18:57:29 +0000 The real bug is presumably https://bugs.freedesktop.org/show_bug.cgi?id=2738 . 587019 48 sgrayban 2008-03-15 01:07:31 +0000 I think Xorg fixed that bug already and your patch in KDE is overkill and causing more bugs. As stated if we remove your code everything works ok. 587475 49 l.lunak 2008-03-17 00:02:19 +0000 Who is comment #48 aimed at? Me? 587477 50 sgrayban 2008-03-17 00:09:24 +0000 yes 587479 51 sgrayban 2008-03-17 00:11:28 +0000 If your patch is suppose to fix a bug, which apparently has been fixed by xorg, and now its causing more problems as with SuperKaramba then your patch needs to be removed. 587573 52 l.lunak 2008-03-17 15:57:23 +0000 No. My patch, which people here are suggesting to remove, was to fix another problem, and only triggers the x.org bug. 587580 53 sgrayban 2008-03-17 16:32:56 +0000 So let me get this straight here. You fixed a KDE program bug that in turn broke another KDE program to fix a bug that was originally xorgs bug? Why should superkaramba users suffer for a program you or others like instead? Is there some order of "My stuff is better then your stuff" rule here? Instead why haven't you forced the bug to be fixed upstream instead of not fixing anything with your patch? Sorry but I just don't follow the logic here and I certainly do not accept it. It is flawed and has caused another program to break. 587636 54 l.lunak 2008-03-17 18:46:20 +0000 No. Read what I wrote again. I fixed an unrelated problem and the fix triggers x.org bug. 587642 55 sgrayban 2008-03-17 19:00:00 +0000 Your *unrelated* problem is about window focus, bug #128648, which in turn broke SK. Do you not agree? I don't have any window focus issues with or without your patch. So I still fail to see how *your* patch has helped. 588443 56 l.lunak 2008-03-20 18:39:58 +0000 *** Bug 138196 has been marked as a duplicate of this bug. *** 590383 57 jaguarwan 2008-03-30 06:08:57 +0000 So, in the end, will this bug be fixed in the next version of KDE 3.5 ? 590555 58 sgrayban 2008-03-31 00:57:15 +0000 looks like never from the answer i got 590610 59 jaguarwan 2008-03-31 10:27:48 +0000 This bug pesters a lot of users since a long time, it would be nice if it could be fixed in one way or another in KDE 3.5.10. I find it quite funny than Alex from #138196 came up with the same patch in december :) 590622 60 l.lunak 2008-03-31 10:58:41 +0000 *sigh* This will not be fixed in KDE, since the bug is not in KDE, unless proven otherwise. The problem is in X and should be fixed in the latest version. Ignoring it or uselessly complaining is not going to change anything about that. 590625 61 sgrayban 2008-03-31 11:14:14 +0000 That is *your* opinion. But on the flip side why don't *you* prove it isn't a KDE bug since you are hell bent it isn't and it's all Xorg's fault. The consensus here says it's a KDE bug. It is up to you to prove other wise since it was *YOU* that caused all this mess. 590626 62 sgrayban 2008-03-31 11:21:30 +0000 The facts are this. I disabled your stupid patch for kwin and *YET* everything works just peachy with my desktop -- even the *assumed* bug for window focus you claimed was there I do not see. It isn't in my version of KDE 3.5.7 nor is it in my 3D desktop so as far as I am concerned your patch broke SuperKaramba and you did it on purpose and you *refuse* to take responsibility for it. All *you* do is blame others. Qt: 3.3.8 KDE: 3.5.7 kde-config: 1.0 Xorg: 7.1.0 590636 63 l.lunak 2008-03-31 12:20:24 +0000 No, the facts are this: The maintainer of the code says there is no bug in the code, while you ... well, what is your qualification actually, besides being apparently clueless about the issue? Come back when you actually do have facts, thank you. For additional input from me, please refer to comment #60. 590638 64 sgrayban 2008-03-31 12:29:09 +0000 Typical god coder reply. Have you worked on GNOME code -- same attitude there as well, "we do no wrong". As for my qualifications -- google me some day. Might learn something. Your patch is crap and that is a fact. 593568 65 24297 alessandrosturniolo 2008-04-11 15:18:44 +0000 Created attachment 24297 Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources (for openSuSE) Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources. Tested only on openSuSE 10.3 593569 66 24298 alessandrosturniolo 2008-04-11 15:19:57 +0000 Created attachment 24298 Gentoo ebuild to revert the code of kwin_layers.cpp. 593570 67 alessandrosturniolo 2008-04-11 15:23:47 +0000 For all those people that don't care about what is the best code, but wants only that the code works (as I am), I've done a script and an ebuild, to revert the code of kwin_layers.cpp, without rebuild entire kdebase3 sources. The script, is for RPM based distros, but I've tested only on openSuSE 10.3. The ebuild is (obviously) for Gentoo. Have a nice day. 593571 68 sgrayban 2008-04-11 15:26:44 +0000 It's about time that someone did some reverting. Shame the maintainers are so thick headed and do not care. Even when the consensus agrees this patch is crap they still refuse to listen. 593572 69 alessandrosturniolo 2008-04-11 15:32:48 +0000 I've done the script and the ebuild, for the users, not for the maintainers. If some other user want a working code (ugly but working) can use my script, or my ebuild, otherwise he can ignore all my crap. 593573 70 sgrayban 2008-04-11 15:35:56 +0000 The maintainers don't care so I wouldn't worry about them. 600073 71 decha 2008-05-10 10:26:38 +0000 Same issue here, Gentoo, kde-3.5.9. Hope there would be some progress, have to stop using superkaramba for now... 641836 72 jaguarwan 2008-08-28 19:19:53 +0000 Hi, I just installed KDE 3.5.10 on my Slackware-current running X.Org 1.4.2, and the bug is still alive and kicking. I'm about to recompile kdebase with my patch again... It'd be nice if this patch could be applied upstream for KDE 3.5.11, since it's quite an annoying bug. For what it's worth, here's the patch against 3.5.10...: --- kdebase-3.5.6/kdebase-3.5.6/kwin/layers.cpp 2007-01-15 12:32:14.000000000 +0100 +++ kdebase-3.5.5/kdebase-3.5.5/kwin/layers.cpp 2006-05-22 20:13:01.000000000 +0200 @@ -117,11 +117,7 @@ } #endif if( changed || propagate_new_clients ) - { propagateClients( propagate_new_clients ); - if( active_client ) - active_client->updateMouseGrab(); - } } /*! 641838 73 27112 jaguarwan 2008-08-28 19:21:06 +0000 Created attachment 27112 Fix the 100% CPU issue with SuperKaramba and Kwin Hope this helps. 649654 74 jacopods+kde 2008-09-29 06:13:45 +0000 Can anybody confirm that the patch fixes the problem? I'm running the patched version and the cpu usage of X when idling keeps increasing as before (altough I did not wait to see if it was eventually going to freeze the system) I'm running 3.5.9 if that matters anymore. Thx 649657 75 sgrayban 2008-09-29 06:57:34 +0000 I stopped using superkaramba since the KDE developers broke it and refuse to fix it. Since then I haven't gave KDE any good reviews seeing they don't care about correct/quality coding. 793684 76 mikebwilliams 2009-07-16 23:49:20 +0000 I'm closing this because the 3.5.X series will likely never see another release (based on all of the discussions I could find on the Internet), let alone one that fixes this instead of security flaws. http://mail.kde.org/pipermail/release-team/2008-August/002390.html 24297 2008-04-11 15:18:44 +0000 2008-04-11 15:18:44 +0000 Revert the code of kwin_layers.cpp without rebuild entire kdebase3 sources (for openSuSE) kwin.patch.tar.bz2 application/octet-stream 1224 alessandrosturniolo QlpoOTFBWSZTWT4wjagAA3b/je5wAEB+f//7/u/ehP///+4BAAABACAACFAEe9N27mctt00aZTgl FNU8p6aam0aAnomQNojINNMmgGQNADQ0NAMkAgyNCTKfqJtQ2k9IGCNB6gAAAMg09QJIQU1T2hpp TwjJoxU0D1B5R6mgBoxND1HqZM9UDIc0xGRk0yaAZDRkMmQAAAyNMjQMIZAlClP1GNUaGnqZB6g9 Q0A0DQHqABoA0eoGgepeM8vKvZ6FicBNVAI28Gotwb23Ke+aVRZ0wkijIogoKFz3tkHZ9y6DmkVb xVu0W7SyOH1Ha0DRFHx3U41pgLMXZ8E6RDNtqeLDf0Mc7N7zeli/I5sWNIPPBIvUgAg+cNfYzM0D u6JA/xPgz8ac8c95dzm6p6Rh4qxKu0EeAsNuU4U1gyzVRWQwSqFNJRZOKAZKzwkvw3w1GopUhHnz 4w8AnKDKdSr5VSkMYjJZPVnrZvGO3m8RvDlDto9cbAZHBhEmInceBsXE+xVXLgzaZNbk2YzUMMJS AUilMq1Z24NqmhGcylceI+mRkDxYhzGeKNDUtlpKMddx1VHcrEYYVIJsu9PHyXqi2IazKkvdd3p0 +QJ61QrzqwRMV5pVJN2loNyGZsb6MtrImQUCS1ZG44QqJEIjio29TiW9xuDwhda7e7NCvBlNYAt1 klJYsMi0rMtTGvG8diYOMH4Wrr8OEaT2sUMGS2liniXbUhQVLV7qNCD1gTmYy0HrrChC0RB227mV YM1ND0R5Sgi2wLIiEcw5S6xy0hkECs4CybzXRAwKw5yy94LS6Q5aON79jXjQ05DnTGY93NE6NlqP 37/mX72Sfu6vIy0F2PEcYGml8FjTxMglgueyQo60IQzOk9Lpkkow20YPHKDp5rrBHiT8Gs0BIXGs 8igVF4FJ7NZYCEDTgpz3KyVp6OS4NDswMx4ctBZNXqWQxXbaK6RpV7gQYQnL4OUCBNVFMNPqYsob 1i/KCOekl0HkMKA9GHL5aQqQeZImG9mZmbf+KYy2o8hYg3ZeX7miM+YM1VkaWdxinevQPmIRM5hY Z2tvr9pPLV7LWDPozeKePW95rBGzdu3QYLQBwv5zgcBpNV7nIF3jZqZsZE+6lMQnRPVAyoDFkjkI 5kGgVpbrwFlPHFe3kfYlIoY1/yLFhKNOl5FZSV5NfDefmFjDN52rvJKGA02cnJl2jyOi/DEAzLcx tw5jmwbE6CE451+bTppd34SyTOJxYCtWUqkyg2KSSVR82bCmC4IiwTkxXB9wc0uIrMetolcgnVXS p7k/Z0y5eG+mWZ0rf7YxkVcguqPA3BX9DM8KuLCBK6T8LQ8suaAck9R6EWUcoiYyd+8tiADDmAiN L1XHcmZZN8V62cg4bAukTRT9ERULjnOkdKzQW7xoBUKqbgXiEpDoRx/NAy8FHK800FLBVrCjqbck xu9rTK9W5y1ryxXXFZNckVM6u1DcJ52lKZSQ21QtTLRghKEKWtQWq3FoLBeWhkczTheWdOImsRQS KtS5kRJNLzgG7F4CMwYd+i9CtktY9uLsw1mukf4zbICaDuKGDOHqMQk9HhtHrjTT6FIvGun2ILKz LhwOYNhp+eLaz7ePvDEIif4u5IpwoSB8YRtQ 24298 2008-04-11 15:19:57 +0000 2008-04-11 15:19:57 +0000 Gentoo ebuild to revert the code of kwin_layers.cpp. kwin-3.5.8.ebuild application/octet-stream 722 alessandrosturniolo IyBDb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L2tkZS1iYXNlL2t3aW4va3dpbi0zLjUuOC5lYnVp bGQsdiAxLjYgMjAwOC8wMS8zMSAxNTozMjoyNCByYW5nZXIgRXhwICQKCktNTkFNRT1rZGViYXNl Ck1BWEtERVZFUj0kUFYKS01fREVQUkFOR0U9IiRQViAkTUFYS0RFVkVSIgppbmhlcml0IGtkZS1t ZXRhIGV1dGlscwoKREVTQ1JJUFRJT049IktERSB3aW5kb3cgbWFuYWdlciIKS0VZV09SRFM9ImFs cGhhIGFtZDY0IGlhNjQgcHBjIHBwYzY0IHNwYXJjIHg4NiB+eDg2LWZic2QiCklVU0U9ImtkZWhp ZGRlbnZpc2liaWxpdHkgeGNvbXBvc2l0ZSIKUkRFUEVORD0ieGNvbXBvc2l0ZT8gKCB4MTEtbGli cy9saWJYY29tcG9zaXRlIHgxMS1saWJzL2xpYlhkYW1hZ2UgKSIKREVQRU5EPSIke1JERVBFTkR9 IgoKU1JDX1VSST0iJHtTUkNfVVJJfQoJbWlycm9yOi8vZ2VudG9vL2tkZWJhc2UtMy41LXBhdGNo c2V0LTA1LnRhci5iejIiCgpzcmNfY29tcGlsZSgpIHsKCW15Y29uZj0iJG15Y29uZiAkKHVzZV93 aXRoIHhjb21wb3NpdGUgY29tcG9zaXRlKSIKCWVwYXRjaCAke0ZJTEVTRElSfS9rd2luX2xheWVy c19yZXZlcnQuZGlmZgoJa2RlLW1ldGFfc3JjX2NvbXBpbGUKfQo= 27112 2008-08-28 19:21:06 +0000 2008-08-28 19:21:06 +0000 Fix the 100% CPU issue with SuperKaramba and Kwin bugfix143255.diff text/plain 417 jaguarwan LS0tIGtkZWJhc2UtMy41LjYva2RlYmFzZS0zLjUuNi9rd2luL2xheWVycy5jcHAJMjAwNy0wMS0x NSAxMjozMjoxNC4wMDAwMDAwMDAgKzAxMDAKKysrIGtkZWJhc2UtMy41LjUva2RlYmFzZS0zLjUu NS9rd2luL2xheWVycy5jcHAJMjAwNi0wNS0yMiAyMDoxMzowMS4wMDAwMDAwMDAgKzAyMDAKQEAg LTExNywxMSArMTE3LDcgQEAKICAgICAgICAgfQogI2VuZGlmCiAgICAgaWYoIGNoYW5nZWQgfHwg cHJvcGFnYXRlX25ld19jbGllbnRzICkKLSAgICAgICAgewogICAgICAgICBwcm9wYWdhdGVDbGll bnRzKCBwcm9wYWdhdGVfbmV3X2NsaWVudHMgKTsKLSAgICAgICAgaWYoIGFjdGl2ZV9jbGllbnQg KQotICAgICAgICAgICAgYWN0aXZlX2NsaWVudC0+dXBkYXRlTW91c2VHcmFiKCk7Ci0gICAgICAg IH0KICAgICB9CiAKIC8qIQoK