7 Mar
2014
7 Mar
'14
5:48 p.m.
On 03/06/2014 09:57 PM, David C. Rankin wrote:
On 03/06/2014 08:47 PM, David C. Rankin wrote:
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 07:18 PM, Slávek Banko wrote:
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)
On Thursday 06 of March 2014 23:47:54 Timothy
Pearson wrote:
Ahh - it is the systemd user session tracking problem....
> 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.
