6 Mar
2014
6 Mar
'14
4:28 p.m.
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?
--
David C. Rankin, J.D.,P.E.
6 Mar
6 Mar
4:52 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
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
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
5:17 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 10:52 AM, Dr. Nikolaus Klepp wrote:
Am Donnerstag, 6. März 2014 schrieb David C. Rankin:
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.
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
6:29 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 10:52 AM, Dr. Nikolaus Klepp wrote:
Try attaching gdb to the runaway tdepowersave process--that should at
least show you where it is stuck.
Tim
Am Donnerstag, 6. März 2014 schrieb David C.
Rankin:
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. 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
6:55 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 12:29 PM, Timothy Pearson wrote:
Will do - and report back.
--
David C. Rankin, J.D.,P.E.
On 03/06/2014
10:52 AM, Dr. Nikolaus Klepp wrote:
Try attaching gdb to the runaway tdepowersave process--that should at
least show you where it is stuck.
Tim
Am Donnerstag, 6. März 2014 schrieb David C.
Rankin:
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. 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
7:06 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 12:55 PM, David C. Rankin wrote:
On 03/06/2014 12:29 PM, Timothy Pearson wrote:
Will do - and report back.
Darn,
On attaching the debugger to the launch, you get some interesting output, but
then tdepowersave goes back to taking its normal 5-7% of CPU instead of 97% of
CPU. Maybe this just happens on initial startup? Is its failure to register with
systemd the problem? Here is the output:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[FIXME] UNCLASSIFIED DEVICE name: broadcast type: (null) subsystem: clockevents
driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/broadcast] [(null):(null)]
[FIXME] UNCLASSIFIED DEVICE name: clockevent0 type: (null) subsystem:
clockevents driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/clockevent0] [(null):(null)]
TQSocketNotifier: Multiple socket notifiers for same socket 12 and type read
tdepowersave: WARNING: The session is not registered with systemd
[Inferior 1 (process 31672) exited normally]
Is there a way I can configure it to start with the debugger attached on tde
start?
--
David C. Rankin, J.D.,P.E.
On
03/06/2014 10:52 AM, Dr. Nikolaus Klepp wrote:
Try attaching gdb to the runaway tdepowersave process--that should at
least show you where it is stuck.
Tim
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.
7:30 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 01:06 PM, David C. Rankin wrote:
On 03/06/2014 12:55 PM, David C. Rankin wrote:
Tim,
tdepowersave starts at it's normal 5-7% and then steadily climbs in CPU use
until it will take 100% on my box. Attaching the pid to gdb yielded the following:
sudo gdb attach 674
...
0xb7795424 in __kernel_vsyscall ()
(gdb) continue
Continuing the tdepowersave process I watch the CPU use steadily climbing over
the next few minutes. I captured a screenshot at 14%, now it is well over 26% of
the CPU:
http://www.3111skyline.com/dl/dt/trinity/ss/tdeowersave-14percent.jpg
Interrupting tdepowesave in gdb output the following:
^C
Program received signal SIGINT, Interrupt.
0xb5ac1b1f in ?? () from /usr/lib/libdbus-1.so.3
I don't know if that is where it is stuck or if it is stuck at the
__kernel_vsyscall ()?
What would you like me to try?
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 12:29 PM, Timothy Pearson wrote:
Will do - and report back.
Darn,
On attaching the debugger to the launch, you get some interesting output, but
then tdepowersave goes back to taking its normal 5-7% of CPU instead of 97% of
CPU. Maybe this just happens on initial startup? Is its failure to register with
systemd the problem? Here is the output:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[FIXME] UNCLASSIFIED DEVICE name: broadcast type: (null) subsystem: clockevents
driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/broadcast] [(null):(null)]
[FIXME] UNCLASSIFIED DEVICE name: clockevent0 type: (null) subsystem:
clockevents driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/clockevent0] [(null):(null)]
TQSocketNotifier: Multiple socket notifiers for same socket 12 and type read
tdepowersave: WARNING: The session is not registered with systemd
[Inferior 1 (process 31672) exited normally]
Is there a way I can configure it to start with the debugger attached on tde
start?
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
7:35 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 01:30 PM, David C. Rankin wrote:
On 03/06/2014 01:06 PM, David C. Rankin wrote:
Checking the journal, it looks like tdepowersave is in a fight with dbus-1, the
following set of messages repeats over-and-over in the logs. It did not do this
prior to the soft-freeze build yesterday:
Mar 06 13:31:28 valhalla dbus[176]: [system] Rejected send message, 2 matched
rules; type="method_call", sender=":1.37" (uid=1000 pid=674
comm="tdepowersave
[tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12964
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send
message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000
pid=674
comm="tdepowersave [tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12964
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")'
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!
Mar 06 13:31:28 valhalla dbus[176]: [system] Activated service
'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown
return code 1
Mar 06 13:31:28 valhalla dbus[176]: [system] Activating service
name='org.trinitydesktop.hardwarecontrol' (using servicehelper)
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Listening...
Mar 06 13:31:28 valhalla dbus[176]: [system] Successfully activated service
'org.trinitydesktop.hardwarecontrol'
Mar 06 13:31:28 valhalla dbus[176]: [system] Rejected send message, 2 matched
rules; type="method_call", sender=":1.37" (uid=1000 pid=674
comm="tdepowersave
[tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetProvidedSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12966
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send
message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000
pid=674
comm="tdepowersave [tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetProvidedSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12966
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")'
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!
Mar 06 13:31:28 valhalla dbus[176]: [system] Activated service
'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown
return code 1
Mar 06 13:31:28 valhalla dbus[176]: [system] Activating service
name='org.trinitydesktop.hardwarecontrol' (using servicehelper)
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Listening...
Mar 06 13:31:28 valhalla dbus[176]: [system] Successfully activated service
'org.trinitydesktop.hardwarecontrol'
Mar 06 13:31:28 valhalla dbus[176]: [system] Rejected send message, 2 matched
rules; type="method_call", sender=":1.37" (uid=1000 pid=674
comm="tdepowersave
[tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send
message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000
pid=674
comm="tdepowersave [tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")'
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!
Mar 06 13:31:28 valhalla dbus[176]: [system] Activated service
'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown
return code 1
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 12:55 PM, David C. Rankin wrote:
Tim,
tdepowersave starts at it's normal 5-7% and then steadily climbs in CPU use
until it will take 100% on my box. Attaching the pid to gdb yielded the following:
sudo gdb attach 674
...
0xb7795424 in __kernel_vsyscall ()
(gdb) continue
Continuing the tdepowersave process I watch the CPU use steadily climbing over
the next few minutes. I captured a screenshot at 14%, now it is well over 26% of
the CPU:
http://www.3111skyline.com/dl/dt/trinity/ss/tdeowersave-14percent.jpg
Interrupting tdepowesave in gdb output the following:
^C
Program received signal SIGINT, Interrupt.
0xb5ac1b1f in ?? () from /usr/lib/libdbus-1.so.3
I don't know if that is where it is stuck or if it is stuck at the
__kernel_vsyscall ()?
What would you like me to try?
On 03/06/2014 12:29 PM, Timothy Pearson wrote:
Darn,
On attaching the debugger to the launch, you get some interesting output, but
then tdepowersave goes back to taking its normal 5-7% of CPU instead of 97% of
CPU. Maybe this just happens on initial startup? Is its failure to register with
systemd the problem? Here is the output:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[FIXME] UNCLASSIFIED DEVICE name: broadcast type: (null) subsystem: clockevents
driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/broadcast] [(null):(null)]
[FIXME] UNCLASSIFIED DEVICE name: clockevent0 type: (null) subsystem:
clockevents driver: (null) [Node Path: (null)] [Syspath:
/sys/devices/system/clockevents/clockevent0] [(null):(null)]
TQSocketNotifier: Multiple socket notifiers for same socket 12 and type read
tdepowersave: WARNING: The session is not registered with systemd
[Inferior 1 (process 31672) exited normally]
Is there a way I can configure it to start with the debugger attached on tde
start?
> 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
Will do - and report back.
8:58 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 01:35 PM, David C. Rankin wrote:
Checking the journal, it looks like tdepowersave is in
a fight with dbus-1, the
following set of messages repeats over-and-over in the logs. It did not do this
prior to the soft-freeze build yesterday:
Tim,
There are thousands and thousands of sets of these repeating messages in the
system journal. It is huge. It is page of output every second.
--
David C. Rankin, J.D.,P.E.
9:37 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 02:58 PM, David C. Rankin wrote:
On 03/06/2014 01:35 PM, David C. Rankin wrote:
I went ahead and opened http://bugs.pearsoncomputing.net/show_bug.cgi?id=1992 to
track this issue. I opened as a blocker, adjust as necessary.
--
David C. Rankin, J.D.,P.E.
Checking the journal, it looks like tdepowersave
is in a fight with dbus-1, the
following set of messages repeats over-and-over in the logs. It did not do this
prior to the soft-freeze build yesterday:
Tim,
There are thousands and thousands of sets of these repeating messages in the
system journal. It is huge. It is page of output every second.
10:31 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
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.
On 03/06/2014
10:52 AM, Dr. Nikolaus Klepp wrote:
Try attaching gdb to the runaway tdepowersave process--that should at
least show you where it is stuck.
Tim
Am Donnerstag, 6. März 2014 schrieb David C.
Rankin:
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. 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
10:47 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
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:
Try attaching gdb to the runaway tdepowersave process--that should at
least show you where it is stuck.
Tim
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. 
7 Mar
7 Mar
1:18 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
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
2:47 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 07:18 PM, Slávek Banko wrote:
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.
Ahh - it is the systemd user session tracking problem....
--
David C. Rankin, J.D.,P.E.
On
03/06/2014 12:29 PM, Timothy Pearson wrote:
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
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.
3:57 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 08:47 PM, David C. Rankin wrote:
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)
--
David C. Rankin, J.D.,P.E.
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.
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
4:29 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 09:57 PM, David C. Rankin 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.
Or at least in Francios case it is. With arch, you have tdm.service to user
pure-systemd to manager tdm. The tdm.service file for Arch is:
$ cat ~/tde/pbpkg/tde-tdebase/tdm.service
[Unit]
Description=TDE Display Manager
After=systemd-user-sessions.service
[Service]
ExecStart=/opt/trinity/bin/tdm
[Install]
Alias=display-manager.service
This is pure-systed. There is no wrapper script that ultimately launches some
wrapper with "exec something".
In Francios setup on Mageia, that is exactly what happens. The Mageia service
file is:
cat prefdm.service
[Unit]
Description=Display Manager
After=livesys-late.service systemd-user-sessions.service
# On Mageia gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
# Do not stop plymouth, it is done in prefdm if required (or left to the dm)
Conflicts=getty(a)tty1.service plymouth-quit.service
After=getty(a)tty1.service plymouth-quit.service
OnFailure=display-manager-failure.service
[Service]
ExecStart=/etc/X11/prefdm -nodaemon
Restart=always
RestartSec=0
IgnoreSIGPIPE=no
That service file does not launch a display manager, it calls the wrapper
script prefdm which essentially calls /etc/X11/lookupdm to get the name of the
display manager via (45TDE and 45TDE.conf) and then does:
preferred=`/etc/X11/lookupdm "$dm"`
[ -n "$preferred" ] && exec $preferred "$@" >/dev/null
2>&1 </dev/null
That isn't systemd -- that is systemd-sysvcompat. That setup just relies on
getting "EXEC=/opt/trinity/bin/tdm" from 45TDE.conf and then launching it as an
init script.
We need TDE to work with systemd.
--
David C. Rankin, J.D.,P.E.
5:49 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 10:29 PM, David C. Rankin wrote:
On 03/06/2014 09:57 PM, David C. Rankin wrote:
Attempting to launch tdm with an inti script in arch does not fix the user
session problem. After launching with the old init, I still get:
cat XDG_SESSION_ID-init.txt
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=no
IdleSinceHint=1394169840146533
IdleSinceHintMonotonic=610563642
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
( I do get more shutdown/hibernate/suspend options though )
--
David C. Rankin, J.D.,P.E.
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.
Or at least in Francios case it is. With arch, you have tdm.service to user
pure-systemd to manager tdm. The tdm.service file for Arch is:
$ cat ~/tde/pbpkg/tde-tdebase/tdm.service
[Unit]
Description=TDE Display Manager
After=systemd-user-sessions.service
[Service]
ExecStart=/opt/trinity/bin/tdm
[Install]
Alias=display-manager.service
This is pure-systed. There is no wrapper script that ultimately launches some
wrapper with "exec something".
In Francios setup on Mageia, that is exactly what happens. The Mageia service
file is:
cat prefdm.service
[Unit]
Description=Display Manager
After=livesys-late.service systemd-user-sessions.service
# On Mageia gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
# Do not stop plymouth, it is done in prefdm if required (or left to the dm)
Conflicts=getty(a)tty1.service plymouth-quit.service
After=getty(a)tty1.service plymouth-quit.service
OnFailure=display-manager-failure.service
[Service]
ExecStart=/etc/X11/prefdm -nodaemon
Restart=always
RestartSec=0
IgnoreSIGPIPE=no
That service file does not launch a display manager, it calls the wrapper
script prefdm which essentially calls /etc/X11/lookupdm to get the name of the
display manager via (45TDE and 45TDE.conf) and then does:
preferred=`/etc/X11/lookupdm "$dm"`
[ -n "$preferred" ] && exec $preferred "$@" >/dev/null
2>&1 </dev/null
That isn't systemd -- that is systemd-sysvcompat. That setup just relies on
getting "EXEC=/opt/trinity/bin/tdm" from 45TDE.conf and then launching it as
an
init script.
We need TDE to work with systemd.
5:53 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 11:49 PM, David C. Rankin wrote:
On 03/06/2014 10:29 PM, David C. Rankin wrote:
Even though user tracking isn't configured in XDG_SESSION_ID when launched via
init, it does solve the tdepowersave CPU @ 100% problem. It is behaving rather
nicely. No logs filling up, CPU consumption between 2.2-3.3%.
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 09:57 PM, David C. Rankin wrote:
Attempting to launch tdm with an inti script in arch does not fix the user
session problem. After launching with the old init, I still get:
cat XDG_SESSION_ID-init.txt
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=no
IdleSinceHint=1394169840146533
IdleSinceHintMonotonic=610563642
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
( I do get more shutdown/hibernate/suspend options though )
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.
Or at least in Francios case it is. With arch, you have tdm.service to user
pure-systemd to manager tdm. The tdm.service file for Arch is:
$ cat ~/tde/pbpkg/tde-tdebase/tdm.service
[Unit]
Description=TDE Display Manager
After=systemd-user-sessions.service
[Service]
ExecStart=/opt/trinity/bin/tdm
[Install]
Alias=display-manager.service
This is pure-systed. There is no wrapper script that ultimately launches some
wrapper with "exec something".
In Francios setup on Mageia, that is exactly what happens. The Mageia service
file is:
cat prefdm.service
[Unit]
Description=Display Manager
After=livesys-late.service systemd-user-sessions.service
# On Mageia gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
# Do not stop plymouth, it is done in prefdm if required (or left to the dm)
Conflicts=getty(a)tty1.service plymouth-quit.service
After=getty(a)tty1.service plymouth-quit.service
OnFailure=display-manager-failure.service
[Service]
ExecStart=/etc/X11/prefdm -nodaemon
Restart=always
RestartSec=0
IgnoreSIGPIPE=no
That service file does not launch a display manager, it calls the wrapper
script prefdm which essentially calls /etc/X11/lookupdm to get the name of the
display manager via (45TDE and 45TDE.conf) and then does:
preferred=`/etc/X11/lookupdm "$dm"`
[ -n "$preferred" ] && exec $preferred "$@" >/dev/null
2>&1 </dev/null
That isn't systemd -- that is systemd-sysvcompat. That setup just relies on
getting "EXEC=/opt/trinity/bin/tdm" from 45TDE.conf and then launching it as
an
init script.
We need TDE to work with systemd.
6:17 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 11:53 PM, David C. Rankin wrote:
On 03/06/2014 11:49 PM, David C. Rankin wrote:
If I launch tdm with inits in Arch, it also breaks the tdeio_sftp fix (somehow):
00:15 valhalla:~> ps ax | grep tdeio
818 ? S 0:00 tdeio_file [tdeinit] file
/tmp/tdesocket-david/tdelauncherIwNs2T.s
967 ? S 0:00 tdeio_file [tdeinit] file
/tmp/tdesocket-david/tdelauncherIwNs2T.s
968 ? S 0:00 tdeio_sftp [tdeinit] sftp
/tmp/tdesocket-david/tdelauncherIwNs2T.s
982 ? S 0:00 tdeio_uiserver [tdeinit]
983 ? S 0:00 tdeio_file [tdeinit] file
/tmp/tdesocket-david/tdelauncherIwNs2T.s
984 ? S 0:00 tdeio_sftp [tdeinit] sftp
/tmp/tdesocket-david/tdelauncherIwNs2T.s
991 pts/1 S+ 0:00 grep tdeio
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 10:29 PM, David C. Rankin wrote:
Even though user tracking isn't configured in XDG_SESSION_ID when launched via
init, it does solve the tdepowersave CPU @ 100% problem. It is behaving rather
nicely. No logs filling up, CPU consumption between 2.2-3.3%.
On 03/06/2014 09:57 PM, David C. Rankin wrote:
Attempting to launch tdm with an inti script in arch does not fix the user
session problem. After launching with the old init, I still get:
cat XDG_SESSION_ID-init.txt
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=no
IdleSinceHint=1394169840146533
IdleSinceHintMonotonic=610563642
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
( I do get more shutdown/hibernate/suspend options though )
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.
Or at least in Francios case it is. With arch, you have tdm.service to user
pure-systemd to manager tdm. The tdm.service file for Arch is:
$ cat ~/tde/pbpkg/tde-tdebase/tdm.service
[Unit]
Description=TDE Display Manager
After=systemd-user-sessions.service
[Service]
ExecStart=/opt/trinity/bin/tdm
[Install]
Alias=display-manager.service
This is pure-systed. There is no wrapper script that ultimately launches some
wrapper with "exec something".
In Francios setup on Mageia, that is exactly what happens. The Mageia service
file is:
cat prefdm.service
[Unit]
Description=Display Manager
After=livesys-late.service systemd-user-sessions.service
# On Mageia gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
# Do not stop plymouth, it is done in prefdm if required (or left to the dm)
Conflicts=getty(a)tty1.service plymouth-quit.service
After=getty(a)tty1.service plymouth-quit.service
OnFailure=display-manager-failure.service
[Service]
ExecStart=/etc/X11/prefdm -nodaemon
Restart=always
RestartSec=0
IgnoreSIGPIPE=no
That service file does not launch a display manager, it calls the wrapper
script prefdm which essentially calls /etc/X11/lookupdm to get the name of the
display manager via (45TDE and 45TDE.conf) and then does:
preferred=`/etc/X11/lookupdm "$dm"`
[ -n "$preferred" ] && exec $preferred "$@" >/dev/null
2>&1 </dev/null
That isn't systemd -- that is systemd-sysvcompat. That setup just relies on
getting "EXEC=/opt/trinity/bin/tdm" from 45TDE.conf and then launching it as
an
init script.
We need TDE to work with systemd.
7:02 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/06/2014 08:47 PM, David C. Rankin wrote:
Multiseat is an essential feature for many of the enterprise TDE
deployments I am aware of. This should be a blocker feature. :-)
Tim
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: 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.
1:11 p.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/07/2014 01:02 AM, Timothy Pearson wrote:
Done,
systemd - user session tracking/multiseat implementation required
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998
--
David C. Rankin, J.D.,P.E.
On 03/06/2014
08:47 PM, David C. Rankin wrote:
Multiseat is an essential feature for many of the enterprise TDE
deployments I am aware of. This should be a blocker feature. :-)
Tim
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: 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....
8 Mar
8 Mar
1:48 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
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.
1:51 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/07/2014 07:48 PM, David C. Rankin wrote:
On 03/06/2014 09:57 PM, David C. Rankin wrote:
Mar 07 19:42:01 valhalla systemd[1]: Starting TDE Display Manager...
Mar 07 19:42:01 valhalla systemd[1]: Started TDE Display Manager.
Mar 07 19:42:22 valhalla [448]: pam_unix(kde:session): session opened for user
david by (uid=0)
Mar 07 19:44:09 valhalla dbus[183]: [system] Activating service
name='org.trinitydesktop.hardwarecontrol' (using servicehelper)
Mar 07 19:44:09 valhalla dbus[183]: [system] Successfully activated service
'org.trinitydesktop.hardwarecontrol'
Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Listening...
Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Name acquired: :1.9
Mar 07 19:44:11 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Name acquired: org.trinitydesktop.hardwarecontrol
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 08:47 PM, David C. Rankin wrote:
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
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:
>> 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....
7:36 a.m.
New subject: [trinity-devel] BUG - tdepowersave Grabbing 97% of CPU - overheating laptop
On 03/07/2014 07:51 PM, David C. Rankin wrote:
On 03/07/2014 07:48 PM, David C. Rankin wrote:
Grrr!!
This error is atavistic. When restarting tdm (with the systemd patches),
tde_dbus_hardwarecontrol works properly, but on subsequent reboots loading from
login, I have experienced the old error:
Mar 06 13:31:28 valhalla dbus[176]: [system] Activating service
name='org.trinitydesktop.hardwarecontrol' (using servicehelper)
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Listening...
Mar 06 13:31:28 valhalla dbus[176]: [system] Successfully activated service
'org.trinitydesktop.hardwarecontrol'
Mar 06 13:31:28 valhalla dbus[176]: [system] Rejected send message, 2 matched
rules; type="method_call", sender=":1.37" (uid=1000 pid=674
comm="tdepowersave
[tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send
message, 2 matched rules; type="method_call", sender=":1.37" (uid=1000
pid=674
comm="tdepowersave [tdeinit] ")
interface="org.trinitydesktop.hardwarecontrol.InputEvents"
member="GetActiveSwitches" error name="(unset)"
requested_reply="0"
destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=12968
comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")'
Mar 06 13:31:28 valhalla org.trinitydesktop.hardwarecontrol[176]:
[tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!
Mar 06 13:31:28 valhalla dbus[176]: [system] Activated service
'org.trinitydesktop.hardwarecontrol' failed: Launch helper exited with unknown
return code 1
--
David C. Rankin, J.D.,P.E.
On 03/06/2014 09:57 PM, David C. Rankin wrote:
Mar 07 19:42:01 valhalla systemd[1]: Starting TDE Display Manager...
Mar 07 19:42:01 valhalla systemd[1]: Started TDE Display Manager.
Mar 07 19:42:22 valhalla [448]: pam_unix(kde:session): session opened for user
david by (uid=0)
Mar 07 19:44:09 valhalla dbus[183]: [system] Activating service
name='org.trinitydesktop.hardwarecontrol' (using servicehelper)
Mar 07 19:44:09 valhalla dbus[183]: [system] Successfully activated service
'org.trinitydesktop.hardwarecontrol'
Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Listening...
Mar 07 19:44:10 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Name acquired: :1.9
Mar 07 19:44:11 valhalla org.trinitydesktop.hardwarecontrol[183]:
[tde_dbus_hardwarecontrol] Name acquired: org.trinitydesktop.hardwarecontrol
On 03/06/2014 08:47 PM, David C. Rankin wrote:
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
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:
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)
3946
days inactive
3948
days old
23 comments
4 participants
participants (4)
-
David C. Rankin -
Dr. Nikolaus Klepp -
Slávek Banko -
Timothy Pearson