Re: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop

On 03/06/2014 07:18 PM, Slávek Banko wrote: > On Thursday 06 of March 2014 23:47:54 Timothy Pearson wrote: >>> On 03/06/2014 12:29 PM, Timothy Pearson wrote: >>>>> On 03/06/2014 10:52 AM, Dr. Nikolaus Klepp wrote: >>>>>> Am Donnerstag, 6. März 2014 schrieb David C. Rankin: >>>>>>> All, >>>>>>> >>>>>>> Testing the new soft-freeze packages has disclosed a horrible >>>>>>> problem >>>>>>> with >>>>>>> tdepowersave taking nearly 100% of the CPU. My laptop was nearly on >>>>>>> fire this >>>>>>> morning: >>>>>>> >>>>>>> [screenshot] >>>>>>> http://www.3111skyline.com/dl/dt/trinity/ss/tdeowersave-97percent.jpg >>>>>>> >>>>>>> Earlier in development I saw tdepowesave in the 20-40% range, but >>>>>>> never at >>>>>>> near 100% of CPU. What to try? >>>>>> >>>>>> What kernel do you use? I had the same problem on wheezy with >>>>>> 3.5.13.2. >>>>>> tdepowersave took 100% of one core. It occured after tdepowersave put >>>>>> the x61 to powersave the second time. It looks like the problem went >>>>>> away after changing to kernel 3.12-0.bpo.1. >>>>>> >>>>>> nik >>>>> >>>>> Kernel is 3.13-5.1 (just a few days old), So this is happening with >>>>> current kernels. >>>>> >>>>> -- >>>>> David C. Rankin, J.D.,P.E. >>>> >>>> Try attaching gdb to the runaway tdepowersave process--that should at >>>> least show you where it is stuck. >>>> >>>> Tim >>> >>> Here is where the tdepowersave generates all the error >>> (TQEventLoop::activateTimers) : >>> >>> TQTimerEvent (timerId=122, this=0xbf894650) at kernel/ntqevent.h:169 >>> 169 kernel/ntqevent.h: No such file or directory. >>> TQEventLoop::activateTimers (this=this@entry=0x98a9d38) at >>> kernel/qeventloop_unix.cpp:564 >>> 564 kernel/qeventloop_unix.cpp: No such file or directory. >>> TQApplication::sendEvent (receiver=0x9977db0, >>> event=event@entry=0xbf894650) at >>> kernel/qapplication.cpp:2456 >>> 2456 kernel/qapplication.cpp: No such file or directory. >>> 2457 in kernel/qapplication.cpp >>> TQEventLoop::activateTimers (this=this@entry=0x98a9d38) at >>> kernel/qeventloop_unix.cpp:565 >>> 565 kernel/qeventloop_unix.cpp: No such file or directory. >>> >>> -- >>> David C. Rankin, J.D.,P.E. >> >> From what you posted earlier this is a dbus-related problem. I don't >> recognize the error messages, so I don't think it's coming from code I >> wrote. :-) >> >> Slavek, did you change tdepowersave to include more dbus support in the >> past few months? >> >> Thanks! >> >> Tim >> > > I see it as a combination of several pieces: > > 1) Commit a7e4c6b5 added to tdehw-lib support for reading the state of the > switches on the input event devices - through tde_dbus_hardwarecontrol == > dbus calls. > 2) In the case of David because of pending issues arch + systemd × pam not > working properly communication with tde_dbus_hardwarecontrol. > 3) tdehw-lib monitor the status by constant rereading hardware devices => > repeated dbus communication with tde_dbus_hardwarecontrol (see 1) ) => for > David see problem 2). > > > The key factor seems to be the problem 2) > > I have a test machine with Ubuntu 13.10 (Saucy), which also uses systemd > (consolekit uninstalled) and without any intervention session works > correctly. François reports some RPM distributions that use systemd also > without problems. I plan to add setting XDG_SESSION_CLASS to 'greeter' in > TDM. However, I do not know if it will help for Arch. > > Other things that could be addressed are: > 1) Resolve the situation so that when the user is not authorized to use > tde_dbus_hardwarecontrol that communication was not repeated. But this looks > like it could be "ugly hack". > 2) Change the method of tracking changes in tdehw-lib to avoid having to > constantly process the device tree. This looks to be useful in the long run, > but now is not the time for such changes. > Ahh - it is the systemd user session tracking problem....