6 Mar
2014
6 Mar
'14
5:18 p.m.
On Thursday 06 of March 2014 23:47:54 Timothy Pearson wrote:
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.
--
Slavek
On 03/06/2014
12:29 PM, Timothy Pearson wrote:
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
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 