On 03/07/2014 07:51 PM, David C. Rankin wrote: > 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 > Grrr!! This error is atavistic. When restarting tdm (with the systemd patches), tde_dbus_hardwarecontrol works properly, but on subsequent reboots loading from login, I have experienced the old error: Mar 06 13:31:28 valhalla dbus[176]: [system] Activating service name='org.trinitydesktop.hardwarecontrol' (using servicehelper) Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]: [tde_dbus_hardwarecontrol] Listening... Mar 06 13:31:28 valhalla dbus[176]: [system] Successfully activated service 'org.trinitydesktop.hardwarecontrol' Mar 06 13:31:28 valhalla dbus[176]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000 pid=674 comm="tdepowersave [tdeinit] ") interface="org.trinitydesktop.hardwarecontrol.InputEvents" member="GetActiveSwitches" error name="(unset)" requested_reply="0" destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ") Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]: [tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000 pid=674 comm="tdepowersave [tdeinit] ") interface="org.trinitydesktop.hardwarecontrol.InputEvents" member="GetActiveSwitches" error name="(unset)" requested_reply="0" destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")' Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]: [tde_dbus_hardwarecontrol] Not primary owner (-1), exiting! Mar 06 13:31:28 valhalla dbus[176]: [system] Activated service 'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown return code 1 -- David C. Rankin, J.D.,P.E.
