On 03/07/2014 01:02 AM, Timothy Pearson 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:
- 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:
- 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
Done,
systemd - user session tracking/multiseat implementation required http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998