This bug report derives from http://bugs.gentoo.org/show_bug.cgi?id=96538: Without identifiable cause X does sometimes (well, too often to work with the system) heavily load the CPU. strace -p freezes the machine most of the time. I was able to provide a log with shows an endless gettimeofday loop. gettimeofday({1119210368, 403147}, NULL) = 0 read(26, "5\30\4\0002\301\252\2F\0\0\0 \0 \0>\377\7\0\313\306\273"..., 4120) = 4120 read(26, "\377\377\377\377\377\377\377\377\250\250\250\377\375\375"..., 260) = 260 read(26, "5\1\4\0006\301\252\2F\0\0\0 \0 \0007\377\4\0007\301\252"..., 4120) = 1416 writev(26, [{"\16\211m\"4\301\252\2\0\0>\r\0\0\0\0\0\0\0\0 \0\0\0 \0"..., 64}, {"\377\377\377\377\241\241\241\377\317\317\317 \377\317\317"..., 4096}], 2) = 4160 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1119210368, 404304}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 469000}) = 1 (in [26], left {1344, 469000}) gettimeofday({1119210368, 404716}, NULL) = 0 read(26, "I\2\5\0:\304\273\2\0\0\0\0 \0 \0\377\377\377\377", 4120) = 20 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) writev(26, [{"\1\10\203\"\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0@V\223"..., 1056}], 1) = 1056 gettimeofday({1119210368, 405298}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 468000}) = 1 (in [26], left {1344, 468000}) gettimeofday({1119210368, 405831}, NULL) = 0 read(26, "5\30\4\0<\301\252\2F\0\0\0 \0 \0>\377\7\0007\304\273\2"..., 4120) = 4120 read(26, "\377\377\377\377\377\377\377\377\250\250\250\377\375\375"..., 260) = 260 read(26, "5\1\4\0@\301\252\2F\0\0\0 \0 \0007\377\4\0A\301\252\2@"..., 4120) = 1416 writev(26, [{"\16A\217\">\301\252\2\0\0>\t\0\0\0\0\0\0\0\0 \0\0\0 \0"..., 64}, {"\377\377\377\377\377\377\377\377\317\317\317 \377\317\317"..., 4096}], 2) = 4160 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1119210368, 407633}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 466000}) = 1 (in [19], left {1344, 466000})
Created attachment 2930 [details] [review] Test case and fix, ready for CVS.
Created attachment 2931 [details] clip-nesting-image-out.png
I have this problem on my SuSE 9.3 desktop and my gentoo notebook, two quite different systems. I run nx and vnc on demand.
Well, the machine freezes when I try to attach to the X process with gdb (so does strace -p) :(
gdb backtrace in such situations: #0 0xffffe410 in ?? () #1 0xbffff688 in ?? () #2 0x00000000 in ?? () #3 0x08216440 in AnyClientsWriteBlocked () #4 0xb7f0df9d in ___newselect_nocancel () from /lib/tls/libc.so.6 #5 0x080e477e in WaitForSomething () #6 0x080c5c15 in Dispatch () #7 0x080d29d6 in main ()
I have relatively high X load right now however fat from the usual 70+%: CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt Processes with a thread ID of 14147 Processes with a thread ID of 14558 Processes with a thread ID of all samples % samples % samples % image name symbol name 175 11.8403 68 1.1210 0 0 Xorg XYToWindow 111 7.5101 579 9.5450 0 0 libc-2.3.5.so (no symbols) 83 5.6157 0 0 0 0 vmlinux unix_poll 56 3.7889 0 0 0 0 vmlinux do_select 54 3.6536 0 0 0 0 vmlinux fget 53 3.5859 0 0 0 0 vmlinux sock_poll 39 2.6387 0 0 0 0 vmlinux __copy_to_user_ll 35 2.3681 0 0 0 0 vmlinux add_wait_queue 34 2.3004 0 0 0 0 vmlinux schedule 33 2.2327 127 2.0936 16 0.8408 Xorg StandardReadRequestFromClient 31 2.0974 89 1.4672 0 0 Xorg SecurityLookupIDByType 30 2.0298 156 2.5717 0 0 Xorg SecurityLookupIDByClass 28 1.8945 0 0 0 0 vmlinux remove_wait_queue 22 1.4885 0 0 0 0 vmlinux buffered_rmqueue 21 1.4208 101 1.6650 29 1.5239 Xorg WaitForSomething 20 1.3532 104 1.7145 9 0.4729 Xorg FlushClientCaches
X just reached the 85+ right now. oprofile look quite the same however: CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt Processes with a thread ID of 14147 Processes with a thread ID of 14558 Processes with a thread ID of all samples % samples % samples % image name symbol name 175 11.8403 191 1.8374 0 0 Xorg XYToWindow 111 7.5101 911 8.7638 0 0 libc-2.3.5.so (no symbols) 83 5.6157 0 0 0 0 vmlinux unix_poll 56 3.7889 0 0 0 0 vmlinux do_select 54 3.6536 0 0 0 0 vmlinux fget 53 3.5859 0 0 0 0 vmlinux sock_poll 39 2.6387 0 0 0 0 vmlinux __copy_to_user_ll 35 2.3681 0 0 0 0 vmlinux add_wait_queue 34 2.3004 0 0 0 0 vmlinux schedule 33 2.2327 214 2.0587 16 0.8408 Xorg StandardReadRequestFromClient 31 2.0974 158 1.5200 0 0 Xorg SecurityLookupIDByType 30 2.0298 232 2.2318 0 0 Xorg SecurityLookupIDByClass 28 1.8945 0 0 0 0 vmlinux remove_wait_queue 22 1.4885 0 0 0 0 vmlinux buffered_rmqueue 21 1.4208 161 1.5488 29 1.5239 Xorg WaitForSomething 20 1.3532 146 1.4045 9 0.4729 Xorg FlushClientCaches
I seem to have the same problem. I can reproduce it by running prboom for a while, sometimes it occurs only after a few hours. I'm running it inside a window, haven't tested fullscreen. The problem starts by X nothing responding responding anymore. I can continue to move the mouse cursor for a short while, then that also freezes. The music of prboom continues. gdb shows me a long backtrace with a lot of question marks, and it also involves gettimeofday() and AnyClientsWriteBlocked(). If there is any specific information I can provide to help solve this problem, please let me know. By the way, any idea what causes the weird addresses like address 0x00000000 and 0xffffe410 in the gdb backtrace? I see addresses like these, too.
I didn't have had the problem for the last 2 weeks. I turned off kcompmgr (and use xcompmgr), don't use kooldock anymore and uninstalled gtk-qt-engine. I don't know which of the three might have triggered the problem or if it even was a synergetic effect. As I do have the problem on my private machines which I run X only for a few hours in the evening on it's hard to make a reliable statement here.
It's a bit early to tell, but I don't seem to be able to reproduce the problem after having added the line Option "NvAgp" "0" to the Device section of the X config file. Section "Device" Identifier "GeForce 6800" Driver "nvidia" Option "NoLogo" "True" Option "CursorShadow" "True" -> Option "NvAgp" "0" EndSection If I understand correctly, this disables AGP support. I'll keep trying for a while longer, and I will experiment with values "1", "2", and "3" ("3" is the default according to /usr/share/doc/nvidia-kernel-1.0.6629-r4/README.gz on my system). If this does solve the problem, I wonder what actually causes the problem: the nvidia kernel module or an nvidia library, or the X server, it could even be bios-related or hardware-related. There seem to be some more bug reports that could be related to this one, just search for "cpu" or for "100" (as in "100%").
I'll try that, too. However I also have this problem on a ATI X600 mobile machine.
kompmgr seems to be the problem or at least part of it. I had a X cpu load of 70% some time after re-activating kompmgr which instantly dropped after I switched kompmgr off.
I filled a KDE bug report: https://bugs.kde.org/show_bug.cgi?id=110358
I just had the problem on my ATI-based notebook w/o (!) kompmgr. The problem was apparently triggered by kooldoock. That is, after pkill -9 kooldock the CPU load instantly dropped to a normal level.
Apparently the problem on my system has a different cause, leading to similar symptoms. The main problem is that the system becomes completely unusable. I think that the X server should keep responding to (some) user events, whatever happens. No process should be able to make the system completely unresponsive. The user should always get a chance to kill a runaway process. Key combinations like CTRL-ALT-BACKSPACE and CTRL-ALT-F1 should keep working so that there is an opportunity to rescue the system without having to resort to the reset button. A warning message with the name and process id of a process that generates events at a high rate in the X server log file or a configurable event rate limiter could also be very helpful.
Again, 80+%. Without any cause. sysprof also doesn't reveal more details (in file /usr/X11R6/bin/Xorg)...
Also, I noticed that X consumes a lot of memory after some hours (i.e. when I let the machine run day and night). Currently X allocates about half a GB RAM. I encountered heavy RAM consumpten earlier *in conjunction* with CPU load.
Original bug reporter e-mail and comments lost in bugzilla disk death. xorg-team archives show: Summary: X "sporadically" heavily loading CPU Product: xorg Version: 6.8.2 Platform: Other OS/Version: Linux Status: NEW Severity: critical Priority: P1 Component: Server/general AssignedTo: xorg-team at lists.x.org ReportedBy: freedesktop at nitwit.de This bug report derives from http://bugs.gentoo.org/show_bug.cgi?id=96538: Without identifiable cause X does sometimes (well, too often to work with the system) heavily load the CPU. strace -p freezes the machine most of the time. I was able to provide a log with shows an endless gettimeofday loop. gettimeofday({1119210368, 403147}, NULL) = 0 read(26, "5\30\4\0002\301\252\2F\0\0\0 \0 \0>\377\7\0\313\306\273"..., 4120) = 4120 read(26, "\377\377\377\377\377\377\377\377\250\250\250\377\375\375"..., 260) = 260 read(26, "5\1\4\0006\301\252\2F\0\0\0 \0 \0007\377\4\0007\301\252"..., 4120) = 1416 writev(26, [{"\16\211m\"4\301\252\2\0\0>\r\0\0\0\0\0\0\0\0 \0\0\0 \0"..., 64}, {"\377\377\377\377\241\241\241\377\317\317\317 \377\317\317"..., 4096}], 2) = 4160 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1119210368, 404304}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 469000}) = 1 (in [26], left {1344, 469000}) gettimeofday({1119210368, 404716}, NULL) = 0 read(26, "I\2\5\0:\304\273\2\0\0\0\0 \0 \0\377\377\377\377", 4120) = 20 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) writev(26, [{"\1\10\203\"\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 at V\223"..., 1056}], 1) = 1056 gettimeofday({1119210368, 405298}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 468000}) = 1 (in [26], left {1344, 468000}) gettimeofday({1119210368, 405831}, NULL) = 0 read(26, "5\30\4\0<\301\252\2F\0\0\0 \0 \0>\377\7\0007\304\273\2"..., 4120) = 4120 read(26, "\377\377\377\377\377\377\377\377\250\250\250\377\375\375"..., 260) = 260 read(26, "5\1\4\0@\301\252\2F\0\0\0 \0 \0007\377\4\0A\301\252\2@"..., 4120) = 1416 writev(26, [{"\16A\217\">\301\252\2\0\0>\t\0\0\0\0\0\0\0\0 \0\0\0 \0"..., 64}, {"\377\377\377\377\377\377\377\377\317\317\317 \377\317\317"..., 4096}], 2) = 4160 read(26, 0xd935640, 4120) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1119210368, 407633}, NULL) = 0 select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38], NULL, NULL, {1344, 466000}) = 1 (in [19], left {1344, 466000}) ------- Additional Comments From freedesktop at nitwit.de 2005-06-20 11:31 ------- Created an attachment (id=2930) --> (https://bugs.freedesktop.org/attachment.cgi?id=2930&action=view) strace X log ------- Additional Comments From freedesktop at nitwit.de 2005-06-20 11:32 ------- Created an attachment (id=2931) --> (https://bugs.freedesktop.org/attachment.cgi?id=2931&action=view) strace -p X log
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
very mysterious old bug, and reporter's account was lost in disk death. -> closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.