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.

-- 
Slavek