RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 601733 - X/getty race condition causes 100% CPU usage
Summary: X/getty race condition causes 100% CPU usage
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kdebase-workspace
Version: 6.0
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jan Grulich
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-08 14:22 UTC by Gordan Bobic
Modified: 2017-12-06 11:15 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 585604
Environment:
Last Closed: 2017-12-06 11:15:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
/etc/sysconfig/init (1.07 KB, application/octet-stream)
2010-06-25 10:14 UTC, Gordan Bobic 		no flags Details
/etc/init/tty.conf (156 bytes, application/octet-stream)
2010-06-25 10:14 UTC, Gordan Bobic 		no flags Details
/etc/init/start-ttys.conf (329 bytes, application/octet-stream)
2010-06-25 10:15 UTC, Gordan Bobic 		no flags Details
View All

Description Gordan Bobic 2010-06-08 14:22:11 UTC 
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
Comment 2 RHEL Program Management 2010-06-08 14:33:20 UTC 
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.
Comment 3 Gordan Bobic 2010-06-10 19:59:32 UTC 
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.
Comment 5 Jaroslav Reznik 2010-06-24 13:45:38 UTC 
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.
Comment 6 Gordan Bobic 2010-06-24 14:00:22 UTC 
# ck-list-sessions | grep x11-display-device
	x11-display-device = '/dev/tty5'

Note - this is with tty5 and tty6 disabled as listed previously.
Comment 7 Jaroslav Reznik 2010-06-24 14:58:39 UTC 
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)?
Comment 8 Gordan Bobic 2010-06-24 15:04:28 UTC 
# 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.
Comment 9 Roman Rakus 2010-06-24 15:14:09 UTC 
I guess this will be somehow related to configuration of /dev/ttyN devices.
Comment 10 Jaroslav Reznik 2010-06-25 10:05:35 UTC 
(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).
Comment 11 Gordan Bobic 2010-06-25 10:12:52 UTC 
My X seems to be running on /dev/tty5.

I'm attaching my /etc/init/tty.conf and /etc/init/start-ttys.conf
Comment 12 Gordan Bobic 2010-06-25 10:14:17 UTC 
Created attachment 426834 [details]
/etc/sysconfig/init
Comment 13 Gordan Bobic 2010-06-25 10:14:53 UTC 
Created attachment 426835 [details]
/etc/init/tty.conf
Comment 14 Gordan Bobic 2010-06-25 10:15:37 UTC 
Created attachment 426836 [details]
/etc/init/start-ttys.conf
Comment 15 Jaroslav Reznik 2010-06-25 11:26:15 UTC 
Do you have login active on tty1 (assuming you're in runlevel 5)? 

Default setup reserves /dev/tty1 for X server in runlevel 5.
Comment 16 Gordan Bobic 2010-06-25 11:37:25 UTC 
No, there is no getty running on tty1.
Comment 17 Jaroslav Reznik 2010-06-25 13:27:44 UTC 
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.
Comment 18 Gordan Bobic 2010-06-28 12:58:19 UTC 
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'
Comment 19 Gordan Bobic 2010-06-28 13:16:45 UTC 
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.
Comment 20 Jaroslav Reznik 2010-06-29 11:53:24 UTC 
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.
Comment 21 Gordan Bobic 2010-06-29 12:04:58 UTC 
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.
Comment 22 Gordan Bobic 2010-06-30 19:18:52 UTC 
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'
Comment 23 Gordan Bobic 2010-07-09 10:00:22 UTC 
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?
Comment 24 RHEL Program Management 2010-07-15 14:44:52 UTC 
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. **
Comment 25 Gordan Bobic 2010-07-15 14:58:22 UTC 
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?
Comment 26 Gordan Bobic 2010-07-15 14:59:35 UTC 
For the sake of completeness, here is the desktop configuration:

# cat /etc/sysconfig/desktop 
DESKTOP=KDE
DISPLAYMANAGER=KDE
Comment 28 RHEL Program Management 2011-01-07 15:51:42 UTC 
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.
Comment 29 Jan Kurik 2017-12-06 11:15:31 UTC 
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/
Note You need to log in before you can comment on or make changes to this bug.