Hide Forgot
This bug is cloned from: https://bugzilla.redhat.com/show_bug.cgi?id=585604 Since the source of the problem is not where it was originally believed to be and since the original bug report is closed, I am opening this new one with additional info. Please see the old bug report for attached logs, if required. The top CPU using processes are consistently these two: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1671 root 40 0 112m 18m 5800 R 99.4 0.6 34:10.87 X 1993 gordan 40 0 859m 22m 14m S 2.3 0.7 0:41.16 knotify4 It seems the issue is related to this KDE bug dating back to 2008. https://bugs.kde.org/show_bug.cgi?id=174897 The bug in question is in KDE's powerdevil. Removing (or disabling) powerdevil libraries cures the problem: # ls -la /usr/lib64/kde4/*powerdevil* ----------. 1 root root 193992 Feb 17 14:31 /usr/lib64/kde4/kcm_powerdevilconfig.so.bak ----------. 1 root root 188936 Feb 17 14:31 /usr/lib64/kde4/kded_powerdevil.so.bak ----------. 1 root root 55120 Feb 17 14:31 /usr/lib64/kde4/krunner_powerdevil.so.bak X process CPU usage is now back down to around 0. This is, of course, a gross hack, but disabling KDE power management with an axe in this way yields far better battery life than running the CPU constantly at 100%. It may be worth investigating how a bug that appears to have been patched upstream for 18 months has managed to get into RHEL6b. Package version this was tested with is: kdebase-workspace-4.3.4-13.el6.x86_64
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
I believe I have found another issue related to this. Removing the powerdevil libraries fixed the problem in almost all cases for me. But every once in a while, the problem would still re-occur (it was happening consistently every time with the powerdevil libraries in place). However, whenever it still happened that X gets stuck at 100% CPU usage, this bug was all over my /var/log/messages: https://bugzilla.redhat.com/show_bug.cgi?id=601674 So I disabled getty on tty5 and tty6 in /etc/sysconfig/init: ACTIVE_CONSOLES=/dev/tty[1-4] and in /etc/init/start-ttys.conf: env ACTIVE_CONSOLES=/dev/tty[1-4] and that seems to have cured the rest of the problem. In fact, with getty 5 and 6 disabled, even putting the powerdevil libraries back doesn't seem to get X stuck at 100% CPU any more (and the powerdevil functionality is now back, so I'm sure it's loaded). How these could possibly be related I have absolutely no idea, but so far the results seem to be consistent and repeatable.
I don't think it's PowerDevil issue but looks like another instance of getty/Xorg race condition. Do you use graphical boot - Plymouth with kernel modesetting? Please, could you provide output for ck-list-sessions | grep x11-display-device Thanks.
# ck-list-sessions | grep x11-display-device x11-display-device = '/dev/tty5' Note - this is with tty5 and tty6 disabled as listed previously.
With tty5 disabled it's OK - KDM should select first free tty. With Plymouth on it reuses tty1. cat /etc/kde/kdm/kdmrc | grep ServerVTs it should be -1 Do you have Plymouth on (graphical boot)?
# cat /etc/kde/kdm/kdmrc | grep ServerVTs ServerVTs=-1 I don't use graphical boot (rhgb), but do use the (default) high res text mode. Default run level is 5.
I guess this will be somehow related to configuration of /dev/ttyN devices.
(In reply to comment #8) > # cat /etc/kde/kdm/kdmrc | grep ServerVTs > ServerVTs=-1 > > I don't use graphical boot (rhgb), but do use the (default) high res text mode. > Default run level is 5. In this case it should be running on /dev/tty1 (both GDM and KDM behaves correctly for me).
My X seems to be running on /dev/tty5. I'm attaching my /etc/init/tty.conf and /etc/init/start-ttys.conf
Created attachment 426834 [details] /etc/sysconfig/init
Created attachment 426835 [details] /etc/init/tty.conf
Created attachment 426836 [details] /etc/init/start-ttys.conf
Do you have login active on tty1 (assuming you're in runlevel 5)? Default setup reserves /dev/tty1 for X server in runlevel 5.
No, there is no getty running on tty1.
I'm out of ideas - could you try to reboot it with Plymouth enabled (so rhgb on)? And check which tty is used (ck-list-sessions). Thanks.
Still running without rhgb, but now I'm seeing the same issue with mingetty crashes and 100% X CPU usage with the clash seemingly on tty4. Unsurprisingly: # ck-list-sessions | grep x11-display-device x11-display-device = '/dev/tty4'
Just tried with rhgb set on the kernel boot line - X still doesn't run on tty1. It's running on the unused tty5 again, unlike on the previous boot where it randomly decided to start on tty4 for some reason, and trip the mingetty crash as it was going on tty5 before.
Can I ask for /var/log/messages, /var/log/Xorg.* and /etc/kde/kdm/*? And could you try it on different system/reinstall? It looks like some issues with your setup not directly connected to KDM tty selection... I tried it on several machines, I tried to reproduce it manually but I haven't hit this strange behaviour. Thanks.
See logs attached to the bug I previously filed here: https://bugzilla.redhat.com/show_bug.cgi?id=585604 I have already seen this issue on two very different systems: 1) IBM ThinkPad T60 w/ ATI X1400 graphics 2) Dell Mini 1012 with integrated Intel graphics on Atom N450. both running 64-bit version of RHEL6b. I will be putting it on another laptop in the next couple of weeks, and possibly another desktop sooner, so will report back when I reproduce the issue on those.
Just upgraded one of my RHEL6b1 test laptops to RHEL6b2w (upgraded the redhat-release file then did a yum update) and X is still not running on tty1 but on the first free post-getty terminal: # ck-list-sessions | grep x11-display-device x11-display-device = '/dev/tty5'
I just installed RHEL6b2w on a clean machine. I'm now pretty certain that the problem is X running on tty != 1 is KDM specific. With gnome it runs on tty1, with kde it runs on the next available terminal and frequently ends up clashing with mingetty over it. Can you verify on your test setup? Perhaps this bug report should be re-assigned to kdm package?
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. It has been denied for the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
I'd argue this is a blocker, if KDE is considered a supported desktop environment. In the default setup, running KDE with KDM logins this is 100% reproducible, and it occurs every time, unless some of the terminals are disabled. Most importantly, something that causes 100% CPU usage on a laptop is going to annihilate the battery life. It also causes X to not run on tty1. All of those are pretty serious issues, are they not?
For the sake of completeness, here is the desktop configuration: # cat /etc/sysconfig/desktop DESKTOP=KDE DISPLAYMANAGER=KDE
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/