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?
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
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.
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
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
Will do - and report back.
On 03/06/2014 12:55 PM, David C. Rankin 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
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 01:06 PM, David C. Rankin wrote:
On 03/06/2014 12:55 PM, David C. Rankin 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
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?
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 01:30 PM, David C. Rankin wrote:
On 03/06/2014 01:06 PM, David C. Rankin wrote:
On 03/06/2014 12:55 PM, David C. Rankin 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
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?
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?
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
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.
On 03/06/2014 02:58 PM, David C. Rankin wrote:
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.
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.
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.
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
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.
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....
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:
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 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@tty1.service plymouth-quit.service After=getty@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.
On 03/06/2014 10:29 PM, David C. Rankin wrote:
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@tty1.service plymouth-quit.service After=getty@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.
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 )
On 03/06/2014 11:49 PM, David C. Rankin wrote:
On 03/06/2014 10:29 PM, David C. Rankin wrote:
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@tty1.service plymouth-quit.service After=getty@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.
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 )
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 11:53 PM, David C. Rankin wrote:
On 03/06/2014 11:49 PM, David C. Rankin wrote:
On 03/06/2014 10:29 PM, David C. Rankin wrote:
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@tty1.service plymouth-quit.service After=getty@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.
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 )
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%.
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
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
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
On 03/06/2014 09:57 PM, David C. Rankin 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:
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)
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
On 03/07/2014 07:48 PM, David C. Rankin wrote:
On 03/06/2014 09:57 PM, David C. Rankin 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:
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)
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
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/07/2014 07:51 PM, David C. Rankin wrote:
On 03/07/2014 07:48 PM, David C. Rankin wrote:
On 03/06/2014 09:57 PM, David C. Rankin 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:
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)
tdebase-tdm-logind-multiseat_03+greeter.patch
SOLVES THE tdepowersave PROBLEM !!!!!!
HELL YA!
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
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 -
Dr. Nikolaus Klepp -
Slávek Banko -
Timothy Pearson