You are not logged in.
seems like that patch fixes it, at least for me.
Arch64/DWM || My Dropbox referral link
Offline
I have applied this patch a week ago, but today this bug appears again.
Offline
I have applied this patch a week ago, but today this bug appears again.
It's might not the same reason cause your problem. (my friend meets this because of nepomuk). That patch only try to fix it with the ntrack case.
You can use gdb attach to the kded4 process and check the backtrace to see where it got stucked. In the ntrack case, it will stuck at the libntrack-nl.
Offline
It not solved yet . any solation?
Offline
same problem here.
almost after every resume kded4 eats nearly 100% of the cpu.
ntrack version: 1:13-1
Offline
did you tried the deadloop.patch? get the src here.
PS: if you have python(3) installed the build will probably fail.
Arch64/DWM || My Dropbox referral link
Offline
did you tried the deadloop.patch? get the src here.
PS: if you have python(3) installed the build will probably fail.
thanks, that fixed it. (i had to remove python3 before compiling)
Offline
The deadloop patch fixed the problem for me as well. On my netbook kded4 used 100% cpu after every resume. I got ntrack to compile with python3 installed by adding
PYTHON=$( which python2 )
to the configure command line.
Offline
Here's a pkgbuild:
# $Id: PKGBUILD 118407 2011-04-06 16:43:17Z andrea $
# Maintainer: Andrea Scarpino <andrea@archlinux.org>
pkgname=ntrack
pkgver=13
pkgrel=1
epoch=1
pkgdesc="A network connectivity tracking library"
arch=('i686' 'x86_64')
url="http://launchpad.net/ntrack/"
license=('LGPL')
depends=('qt' 'libnl' 'gcc-libs')
makedepends=('python2')
optdepends=('python2')
source=("http://launchpad.net/${pkgname}/main/0${pkgver}/+download/${pkgname}-0${pkgver}.tar.gz" deadloop.patch)
md5sums=('90596b924a108f8b4eea52239ba64369' '7de6d082f5836543064d0f93494623f5')
options=('!libtool')
build() {
cd "${srcdir}/${pkgname}-0${pkgver}"
patch -Np0 < ${srcdir}/deadloop.patch
PYTHON=$( which python2 ) ./configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var
make
}
package() {
cd "${srcdir}/${pkgname}-0${pkgver}"
make DESTDIR="${pkgdir}" install
}
deadloop.patch
--- modules/ntrack-libnl.c~ 2011-03-27 07:37:02.000000000 +0800
+++ modules/ntrack-libnl.c 2011-04-09 23:11:33.919862769 +0800
@@ -375,6 +375,7 @@
get_nl_link_by_index (ntrack_monitor_t *self, ntrack_list_t *linklist, int iindex)
{
ntrack_list_t *i = linklist;
+ ntrack_list_t *head = NULL;
struct rtnl_link *result = NULL;
while (i) {
struct rtnl_link *link = i->data;
@@ -384,6 +385,10 @@
}
if (rtnl_link_get_ifindex(link) > iindex)
break;
+ if (head == i)
+ break;
+ if (head == NULL)
+ head = i;
i = i->next;
}
return result;
Thanks, zeb, for the python fix.
EDIT: Accidentally posted PKGBUILD for version 14 (which doesn't work properly).
Last edited by patstew (2011-05-09 17:33:54)
Offline
simply use PYTHON=/usr/bin/python2 and we better stay with 013 for now.
Arch64/DWM || My Dropbox referral link
Offline
I've the same issue, but it I don't use resume very often. KDE just begins to eat my CPU out of nothing. The temperature of the CPU cores rises pretty fast and I even had freezes because of high CPU temperature.
Offline
And the patch doesn't help?
Freezes because of high temp is a hardware issue and is destructive for CPU, so do something with it.
Offline
same thing. clean install. nepomuk disabled, akonadi disabled. up today packet. without any patches.
Offline
I've been having this same problem, but with both kded4 and knotify4.
After about 5-10 minutes of anything that calls upon the two running (Even outside of KDE4), it goes instantly into it's (OH NOM NOM NOM NOM NOM NOM NOM!) state of eating up my Ram and CPU, and I have 4GB of Ram with 8GB Swap, CPU spikes at 100% and I'm forced to promptly blow both kded4 and knotify4's heads off using xkill or whatever.
I'm updating today to see if anything mentioned in this thread is fixed. I bet it's ntrack but I could be wrong.
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbert Hubbard
OpenBox3 + KDE4.6 + Xfce4.8 User
Offline
Same problem here.
ntrack version: 1:13-1 doesn't help.
But I reduce the CPU usage disabling Nepomuk Semantic Desktop in System Settings / Desktop Search / Basic Settings / Nepomuk Semantic Desktop
I hope it helps until bug is solved.
Offline
ntrack version: 1:13-1 doesn't help.
?? We're at ntrack 1:13-2, which contains the necessary patch.
Last edited by SanskritFritz (2011-06-15 14:10:52)
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
ontobelli wrote:ntrack version: 1:13-1 doesn't help.
?? We're at ntrack 1:13-2, which contains the necessary patch.
Read the thread,
Offline
So, I've read the thread. Thank you, it was very entertaining. What should I do next?
Disclaimer: I obviously missed some very important information about the necessity of downgrading to ntrack 1:13-1. Please share that with me.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline