On 03/07/2014 07:48 PM, David C. Rankin wrote: > On 03/06/2014 09:57 PM, David C. Rankin wrote: >> On 03/06/2014 08:47 PM, David C. Rankin wrote: >>> 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.... >>> >>> >> >> Slavek, >> >> We need to check your and Francios setup. I think your are still using the >> init-script to launch tdm which invokes systemd-sysvcompat (/usr/bin/init) >> instead of pure-systemd. My goal is to have TDE function with pure-systemd. >> >> Arch no longer has any init-scripts and relies solely on systemd. TDE now has >> your dbus patch from tdebase-kdesktop-systemd.diff which has probably solved >> part of the problem. We just now need to solve the rest of the problem. >> >> We probably can do without a complete multiseat implementation, but my latest >> patch in 1902 includes the full port of the kde4 multiseat solution to TDE which >> builds just fine -- I just need help connecting the loose ends. I have that >> patch plus the patch that explicitly sets the 'greeter' pam environment as well. >> Again, it and multiseat build just fine on current TDE, I just need your help >> making sure all the proper connections are made and there are no k->tde Qt->TQt >> issues. The patch is attached: >> >> tdebase-tdm-logind-multiseat_03+greeter.patch >> >> I will also try to figure out the startup files Francios provided, but like >> I've been saying, TDE is in need of systemd migration or these type of problems, >> along with messed up udev/polkit user access will make strike for every install >> that is pure-systemd (not systemd-sysvcompat reliant) >> > > tdebase-tdm-logind-multiseat_03+greeter.patch > > SOLVES THE tdepowersave PROBLEM !!!!!! > > HELL YA! > > Mar 07 19:42:01 valhalla systemd[1]: Starting TDE Display Manager... Mar 07 19:42:01 valhalla systemd[1]: Started TDE Display Manager. Mar 07 19:42:22 valhalla [448]: pam_unix(kde:session): session opened for user david by (uid=0) Mar 07 19:44:09 valhalla dbus[183]: [system] Activating service name='org.trinitydesktop.hardwarecontrol' (using servicehelper) Mar 07 19:44:09 valhalla dbus[183]: [system] Successfully activated service 'org.trinitydesktop.hardwarecontrol' Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]: [tde_dbus_hardwarecontrol] Listening... Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]: [tde_dbus_hardwarecontrol] Name acquired: :1.9 Mar 07 19:44:11 valhalla org.trinitydesktop.hardwarecontrol[183]: [tde_dbus_hardwarecontrol] Name acquired: org.trinitydesktop.hardwarecontrol -- David C. Rankin, J.D.,P.E.
