> 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:

Multiseat is an essential feature for many of the enterprise TDE
deployments I am aware of.  This should be a blocker feature. :-)

Tim