Hi, I wanned fix bug number 690 and get rid of high cpu usage during kdm login screen. So I first tried daily-build and when I get know, that it's not stable for daily use i downgrade to Slavek's pathed 3.5.13 (http://trinity-users.pearsoncomputing.net/?0::2776). In both case, there shoul be that bug fixed.However, problem seems to be still there (on my coputer) and as a bonus I get another one. When there is "Press ctrl+alt+delete" window there, I can try keep pressing these keys, but windows is still there and I can log in. Any advise? How to debug that? Can I reopen this bug?
Regards Jirka
Dne po 20. února 2012 Jiri Jansky napsal(a):
Hi, I wanned fix bug number 690 and get rid of high cpu usage during kdm login screen. So I first tried daily-build and when I get know, that it's not stable for daily use i downgrade to Slavek's pathed 3.5.13 (http://trinity-users.pearsoncomputing.net/?0::2776). In both case, there shoul be that bug fixed.However, problem seems to be still there (on my coputer) and as a bonus I get another one. When there is "Press ctrl+alt+delete" window there, I can try keep pressing these keys, but windows is still there and I can log in. Any advise? How to debug that? Can I reopen this bug?
Regards Jirka
The problem with Ctrl + Alt + Delete is a different bug than 690, so it probably should be reported separately. Meanwhile you can workaround - disable Ctrl + Alt + Delete ;)
Slavek --
Dne 20.2.2012 14:25, Slávek Banko napsal(a):
Dne po 20. února 2012 Jiri Jansky napsal(a):
Hi, I wanned fix bug number 690 and get rid of high cpu usage during kdm login screen. So I first tried daily-build and when I get know, that it's not stable for daily use i downgrade to Slavek's pathed 3.5.13 (http://trinity-users.pearsoncomputing.net/?0::2776). In both case, there shoul be that bug fixed.However, problem seems to be still there (on my coputer) and as a bonus I get another one. When there is "Press ctrl+alt+delete" window there, I can try keep pressing these keys, but windows is still there and I can log in. Any advise? How to debug that? Can I reopen this bug?
Regards Jirka
The problem with Ctrl + Alt + Delete is a different bug than 690, so it probably should be reported separately. Meanwhile you can workaround - disable Ctrl + Alt + Delete ;)
Slavek
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
Dne po 20. února 2012 Jiri Jansky napsal(a):
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
Ouch! That's not good news, if the patch for #690 did not work for you. On my machine it works - the cpu is at rest. You have replaced all packages from the nightly builds to packages from version 3.5.13? Please, can someone give even know if patch for #690 solved the problem with the processor?
Ctrl + Alt + Del I do not know - that I immediately turned off because I consider it unnecessary. To turn off the see /etc/trinity/kdm/kdmrc - UseSAK settings.
Slavek --
Dne po 20. února 2012 Jiri Jansky napsal(a):
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
Ouch! That's not good news, if the patch for #690 did not work for you. On my machine it works - the cpu is at rest. You have replaced all packages from the nightly builds to packages from version 3.5.13? Please, can someone give even know if patch for #690 solved the problem with the processor?
690 fixed it for me...
Tim
Dne po 20. února 2012 Timothy Pearson napsal(a):
Dne po 20. února 2012 Jiri Jansky napsal(a):
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
Ouch! That's not good news, if the patch for #690 did not work for you. On my machine it works - the cpu is at rest. You have replaced all packages from the nightly builds to packages from version 3.5.13? Please, can someone give even know if patch for #690 solved the problem with the processor?
690 fixed it for me...
Tim
I did a little research. On my machine with a 32bit system and off kdm_greet SAK is at rest, so I have not conducted further observations. Much more interesting results but I watched the 64-bit machine.
1. SAK is enabled: The CPU goes to 100%. 2. SAK is enabled: Switching NumLock on a PS/2 keyboard causes the death of the keyboard - everywhere - Xorg, console. USB keyboard switching NumLock survive fine. 3. SAK is enabled: If during the time between pressing the Ctrl + Alt + Delete and SAK display window, I press the Escape, SAK behave strangely. For example, dialog Desktop Session Locked remained displayed and next pressing Ctrl + Alt + Delete keys were ignored. And then kdesktop_lock goes to 100%. 4. SAK is disabled: Switching NumLock on a PS/2 keyboard survive fine. 5. SAK is disabled: CPU goes to 20% initially, but with increasing time of inactivity increases to 80%.
So I have to confirm the observations from Jiri Jansky - kdm_greet is still sick. And SAK from now I consider not only the futility but complete stupidity. :)
Slavek --
On Wednesday 22 February 2012 02:24:25 pm Slávek Banko wrote: <snip>
So I have to confirm the observations from Jiri Jansky - kdm_greet is still sick. And SAK from now I consider not only the futility but complete stupidity. :)
For home users, it is complete stupidity IMO. How many people have friends or relatives who are going to hack the login screen, anyway?
For businesses, schools, etc. that will have a lot of people logging in, I can certainly understand having it enabled, provided it works right. Even then, if the business/school/etc. sets up their read/write permissions correctly and are as careful as possible who they provide root access to, they shouldn't have to worry. Besides, if they give root access to someone who's untrustworthy, that would invalidate any reason for having SAK enabled.
On 22 February 2012 14:52, Kristopher John Gamrat chaotickjg@gmail.com wrote:
On Wednesday 22 February 2012 02:24:25 pm Slávek Banko wrote:
<snip> > So I have to confirm the observations from Jiri Jansky - kdm_greet is > still sick. And SAK from now I consider not only the futility but > complete stupidity. :)
For home users, it is complete stupidity IMO. How many people have friends or relatives who are going to hack the login screen, anyway?
For businesses, schools, etc. that will have a lot of people logging in, I can certainly understand having it enabled, provided it works right. Even then, if the business/school/etc. sets up their read/write permissions correctly and are as careful as possible who they provide root access to, they shouldn't have to worry. Besides, if they give root access to someone who's untrustworthy, that would invalidate any reason for having SAK enabled.
I missed the part where you were actually talking about what SAK implements.
maybe you should read up on it:
http://en.wikipedia.org/wiki/Secure_attention_key
Calvin Morrison
Dne st 22. února 2012 Calvin Morrison napsal(a):
On 22 February 2012 14:52, Kristopher John Gamrat chaotickjg@gmail.com
wrote:
On Wednesday 22 February 2012 02:24:25 pm Slávek Banko wrote:
<snip>
So I have to confirm the observations from Jiri Jansky - kdm_greet is still sick. And SAK from now I consider not only the futility but complete stupidity. :)
For home users, it is complete stupidity IMO. How many people have friends or relatives who are going to hack the login screen, anyway?
For businesses, schools, etc. that will have a lot of people logging in, I can certainly understand having it enabled, provided it works right. Even then, if the business/school/etc. sets up their read/write permissions correctly and are as careful as possible who they provide root access to, they shouldn't have to worry. Besides, if they give root access to someone who's untrustworthy, that would invalidate any reason for having SAK enabled.
I missed the part where you were actually talking about what SAK implements.
maybe you should read up on it:
http://en.wikipedia.org/wiki/Secure_attention_key
Calvin Morrison
Well, SAK I always seemed as pointless. At home, at school, at work, I never saw usefulness. However, there is no need to discuss the usefulness of the SAK, but that kdm seems to be ill. And #690, therefore, seems unresolved.
Slavek --
On Wednesday 22 February 2012 02:55:51 pm Calvin Morrison wrote:
On 22 February 2012 14:52, Kristopher John Gamrat chaotickjg@gmail.com wrote:
On Wednesday 22 February 2012 02:24:25 pm Slávek Banko wrote:
<snip> > So I have to confirm the observations from Jiri Jansky - kdm_greet is > still sick. And SAK from now I consider not only the futility but > complete stupidity. :)
For home users, it is complete stupidity IMO. How many people have friends or relatives who are going to hack the login screen, anyway?
For businesses, schools, etc. that will have a lot of people logging in, I can certainly understand having it enabled, provided it works right. Even then, if the business/school/etc. sets up their read/write permissions correctly and are as careful as possible who they provide root access to, they shouldn't have to worry. Besides, if they give root access to someone who's untrustworthy, that would invalidate any reason for having SAK enabled.
I missed the part where you were actually talking about what SAK implements.
maybe you should read up on it:
You couldn't have missed it because it isn't there to miss.
Why should I read up on it? I already know what it is and what it does. It's to help make sure that the login screen isn't spoofed by a spyware-ridden version.
I did a little research. On my machine with a 32bit system and off kdm_greet SAK is at rest, so I have not conducted further observations. Much more interesting results but I watched the 64-bit machine.
- SAK is enabled: The CPU goes to 100%.
- SAK is enabled: Switching NumLock on a PS/2 keyboard causes the death
of the keyboard - everywhere - Xorg, console. USB keyboard switching NumLock survive fine. 3. SAK is enabled: If during the time between pressing the Ctrl + Alt + Delete and SAK display window, I press the Escape, SAK behave strangely. For example, dialog Desktop Session Locked remained displayed and next pressing Ctrl + Alt + Delete keys were ignored. And then kdesktop_lock goes to 100%. 4. SAK is disabled: Switching NumLock on a PS/2 keyboard survive fine. 5. SAK is disabled: CPU goes to 20% initially, but with increasing time of inactivity increases to 80%.
So I finally disabled SAK (when I tried it first time using kcontrol it doesn't seem work, but second time ok). So I can now use kdm to login again.
As Slavek described, there is still high cpu usage. On my laptop with Pentium M 1.7 MHz undeclocked to 800MHz its 50%.
Jansky
On Wednesday 22 of February 2012 23:48:14 Jiri Jansky wrote:
So I finally disabled SAK (when I tried it first time using kcontrol it doesn't seem work, but second time ok). So I can now use kdm to login again.
As Slavek described, there is still high cpu usage. On my laptop with Pentium M 1.7 MHz undeclocked to 800MHz its 50%.
Jansky
amd64 or i386?
Slavek --
I did a little research. On my machine with a 32bit system and off kdm_greet SAK is at rest, so I have not conducted further observations. Much more interesting results but I watched the 64-bit machine.
- SAK is enabled: The CPU goes to 100%.
- SAK is enabled: Switching NumLock on a PS/2 keyboard causes the death
of the keyboard - everywhere - Xorg, console. USB keyboard switching NumLock survive fine. 3. SAK is enabled: If during the time between pressing the Ctrl + Alt + Delete and SAK display window, I press the Escape, SAK behave strangely. For example, dialog Desktop Session Locked remained displayed and next pressing Ctrl + Alt + Delete keys were ignored. And then kdesktop_lock goes to 100%. 4. SAK is disabled: Switching NumLock on a PS/2 keyboard survive fine. 5. SAK is disabled: CPU goes to 20% initially, but with increasing time of inactivity increases to 80%.
Bug 690 is acording bugzilla fixed by patch 1e2983a. According patch file it's "corrected" by adding usleep(500). If it's usleep in some while loop (I think it's), it's more like some dirty hack, that should be rewritten using some blocking function...
On Wednesday 22 of February 2012 23:57:40 Jiri Jansky wrote:
I did a little research. On my machine with a 32bit system and off kdm_greet SAK is at rest, so I have not conducted further observations. Much more interesting results but I watched the 64-bit machine.
Bug 690 is acording bugzilla fixed by patch 1e2983a. According patch file it's "corrected" by adding usleep(500). If it's usleep in some while loop (I think it's), it's more like some dirty hack, that should be rewritten using some blocking function...
On my 32bit machine where 690 patch helped, I just restarted KDM ... and now my processor also runs at 100% :( I'm afraid that really bug 690 must be re-opened. Added usleep is clearly not a reliable solution
Slávek --
On Wednesday 22 of February 2012 23:57:40 Jiri Jansky wrote:
I did a little research. On my machine with a 32bit system and off kdm_greet SAK is at rest, so I have not conducted further observations. Much more interesting results but I watched the 64-bit machine.
Bug 690 is acording bugzilla fixed by patch 1e2983a. According patch file it's "corrected" by adding usleep(500). If it's usleep in some while loop (I think it's), it's more like some dirty hack, that should be rewritten using some blocking function...
On my 32bit machine where 690 patch helped, I just restarted KDM ... and now my processor also runs at 100% :( I'm afraid that really bug 690 must be re-opened. Added usleep is clearly not a reliable solution
Slávek
Understood. Please reopen it and post some of your hardware details, such as CPU type and speed.
Tim
On 2012 二月 21 星期二, Slávek Banko wrote:
Dne po 20. února 2012 Jiri Jansky napsal(a):
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
Ouch! That's not good news, if the patch for #690 did not work for you. On my machine it works - the cpu is at rest. You have replaced all packages from the nightly builds to packages from version 3.5.13? Please, can someone give even know if patch for #690 solved the problem with the processor?
Ctrl + Alt + Del I do not know - that I immediately turned off because I consider it unnecessary. To turn off the see /etc/trinity/kdm/kdmrc - UseSAK settings.
Slavek
To not only turn off CTRL+ALT+Del for "kdm" but also for "kdesktop_lock": 1. Execute command "kcmshell kdm" -> Uncheck "Enable Secure Attention Key". 2. Manual modify file "~/.trinity/share/config/kdesktoprc" and add a line "UseTDESAK=false" under section "[ScreenSaver]". Refer to trinity-kdebase package's source code "./kdebase/kdesktop/lock/main.cc" for detail.
On Monday 20 February 2012 02:53:15 pm Jiri Jansky wrote:
Dne 20.2.2012 14:25, Slávek Banko napsal(a):
Dne po 20. února 2012 Jiri Jansky napsal(a):
Hi, I wanned fix bug number 690 and get rid of high cpu usage during kdm login screen. So I first tried daily-build and when I get know, that it's not stable for daily use i downgrade to Slavek's pathed 3.5.13 (http://trinity-users.pearsoncomputing.net/?0::2776). In both case, there shoul be that bug fixed.However, problem seems to be still there (on my coputer) and as a bonus I get another one. When there is "Press ctrl+alt+delete" window there, I can try keep pressing these keys, but windows is still there and I can log in. Any advise? How to debug that? Can I reopen this bug?
Regards Jirka
The problem with Ctrl + Alt + Delete is a different bug than 690, so it probably should be reported separately. Meanwhile you can workaround - disable Ctrl + Alt + Delete ;)
Slavek
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
Maybe I am looser, but where can I find disabling ov ctrl+alt+delete?
thanks
Jiri
/etc/inittab
On Monday 20 February 2012 02:53:15 pm Jiri Jansky wrote:
Dne 20.2.2012 14:25, Slávek Banko napsal(a):
Dne po 20. února 2012 Jiri Jansky napsal(a):
Hi, I wanned fix bug number 690 and get rid of high cpu usage during kdm login screen. So I first tried daily-build and when I get know, that it's not stable for daily use i downgrade to Slavek's pathed 3.5.13 (http://trinity-users.pearsoncomputing.net/?0::2776). In both case, there shoul be that bug fixed.However, problem seems to be still there (on my coputer) and as a bonus I get another one. When there is "Press ctrl+alt+delete" window there, I can try keep pressing these keys, but windows is still there and I can log in. Any advise? How to debug that? Can I reopen this bug?
Regards Jirka
The problem with Ctrl + Alt + Delete is a different bug than 690, so it probably should be reported separately. Meanwhile you can workaround - disable Ctrl + Alt + Delete ;)
Slavek
I have problem both with Ctrl + Alt + Delete window and with high cpu usage of kdm_great. So problem with high cpu usage of kdm_great is still there and new problem with ctrl+alt+delete window is another one.
To turn off CTRL+ALT+Del without editing config files, go to Control Center -> System Administration -> Login Manager and click Administrator Mode at the bottom. Uncheck "Enable Secure Attention Key" and apply. CTRL+ALT+Del should now be gone.
-
Baho Utot -
Calvin Morrison -
Chien-Chung Yeh -
Jiri Jansky -
Kristopher John Gamrat -
Slávek Banko -
Timothy Pearson