Red Hat Bugzilla – Bug 150872
Xorg hangs repeatedly utilizing CPU upto 100%
Last modified: 2007-11-30 17:07:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Description of problem:
Xorg hangs (seems to be in the endless loop) repeatedly utilizing CPU
upto 100% during normal "GUI" activity. E.g. often it happens using
gnome-terminal sessions (resizing, moving) or Java-based GUI
applications. Using XTerm causes that hang rarely.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start gnome-terminal in a gnome envieronment, or java-based application
2. make some activity on those GUI (move, resize, perform some actions)
3. switch between workspaces during that activity
Actual Results: Xorg hangs, mouse and keyboard don't react but it is
possible to login to the host from another machine (e.g. via ssh). CPU
is utilized upto 100%:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6780 root 25 0 138m 37m 7244 R 97.7 7.4 670:17.78 X
23519 root 15 0 2236 880 672 R 3.9 0.2 0:00.02 top
1 root 16 0 3628 568 480 S 0.0 0.1 0:00.81 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
3 root 5 -10 0 0 0 S 0.0 0.0 0:00.25 events/0
It seems that it hangs in the endless loop:
=> pstack 6780
6780: /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten
(No symbols found in /usr/lib/libz.so.1)
(No symbols found in /lib/libpam.so.0)
(No symbols found in /lib/libpam_misc.so.0)
(No symbols found in /lib/libgcc_s.so.1)
(No symbols found in /usr/lib/libfreetype.so.6)
0x097bc0a8: _fini + 0x1612f24 (9653d98, 80000, 99e9838, 980e074, 26,
4dc) + 20
0x0981bd1d: _fini + 0x1672b99 (9d90990, 99e9838, a3421c0, 0, 0, a) + 30
0x08159e2d: damageCopyArea + 0x127 (9d90990, 99e9838, a3421c0, 0, 0,
a) + 20
0x080bce1c: ProcCopyArea + 0x209 (9d716c8, 1, 0, 3a020ae, 8, 0) + 420
0x080c1549: Dispatch + 0x148 (2, 0, 93bd278, bfe6f3bc, 900378,
81c4118) + 30
0x080cd31a: main + 0x3f9 (9, bfe6f464, bfe6f48c, 7d6fd4, 8feff4, 0) + 40
0x007eee33: __libc_start_main + 0xe3 (80ccf21, 9, bfe6f464, 81a90c8,
81a911c, 7cd3d0) + 40190ba8
Expected Results: Xorg should not hang!
Seems to be a reoccurence of bug #140600
Please contact Red Hat Global Support Services at 1-888-RED-HAT1 and file
a support ticket for this issue.
It seems to be found also in other distros
https://bugs.freedesktop.org/show_bug.cgi?id=2769 . Unfortunately I also have
this issue un RHEL4AS.
What I suspect to be the problem is the enabling of COMPOSITE extension and
RENDERACCEL on nVidia drivers.
Something must br going wrong here.
Other behaviour that I've noticed, but not with latest nVidia drivers, is a
complete X server reset after exiting the vmware application or even a virtual
The only thing mentioned in the log is "Caught signal 11". Nothing usefull for
debuging. Unfortunately I don't have ptrace on rhel. Is there any method to give
you info on this? I can give you a shell on a locked machine upon request.
Make sure you've upgraded to the latest official RHEL kernel and
xorg-x11 packages, and rebooted into the new kernel, and are not
using any proprietary or 3rd party kernel or video drivers.
If the problem is reproduceable in the latest updates, with any
video hardware, in order to receive official Red Hat support
for the problem, please file a support ticket at
http://www.redhat.com/support or call Red Hat Global Support
Services at 1-888-RED-HAT1, which are our official Red Hat
Enterprise Linux support mechanisms.
Once you've filed an official support request using the above
mechanisms, a Red Hat Global Support Services will provide support
services for the issue. You may wish to refer them to this bugzilla
for reference as well.
I, and an officemate who also FC3's, are seeing the same problem using FC3. I
only see it browsing occasional pages with Firefox. I don't know what causes it
but I have to Kill -9 the X process to break the machine free. The mouse still
moves, but focus will not change and no action can be taken with Gnome.
Ctl-Alt-Fkeys don't even work. I have to log into the box remotely to "recover".
Seems to be fixed with RHEL4 Update2