Xorg uses 100% CPU

Thanks for your bug report. Feisty Fawn, Ubuntu 7.04, actually uses the 2.6.20 kernel. Is your system up to date? Additionally, when you leave the system does a screen saver kick in? Thanks in advance.

Hi, yes what you say about the kernel its true, I already have the 2.6.20 kernel, but I'm using this because it's the one I have configured to use with vmware, but if you want I could try this 2.6.20 a few days to see whats happens, I believe it'ill be the same result. About the second question I don't understand it at all (english it's not my natural language); but I have a screensaver configured at 10 minutes and it's configured so that I don't have to type the password each time. If you could please ask this question with differents words i wouldl answer it.

Could you either try using the 2.6.20 kernel or turning off your screensaver? This will help us narrow down where the problem lies. Thanks again.

Ok here i am again, I've tried both, not just turning off the screensaver but also using the 2.6.20 kernel, and still the same negative results, any other idea?

could you attach the output of /usr/share/bug/xserver-xorg-core/script

the /usr/share/bug/xserver-xorg/script is empty (there's no "xserver-xorg-core"). Any suggestion? Thanks for your time

heh, indeed.. wait for the xorg-server-1.2 upload which will be in feisty shortly, and then try again :)

ok, the new xorg-server is now in. The correct command to run is '/usr/share/bug/xserver-xorg-core/script 3>&1 file' and attach the file.

Ok i did that step, here I attach the flie

that's the script I want you to run with the parameters I gave you ;) That directs the output to a file, and then attach that file to this bug.

I have had a similar issue and executed the script creating the attached log file.

Brian, from Xorg.0.log:

(II) fglrx(0): driver needs X.org 7.1.x.y with x.y >= 0.0
(II) fglrx(0): detected X.org 7.1.0.0
(EE) fglrx(0): GART is not initialized, disabling DRI
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *

maybe that's what's your problem.

Ok, i've just done the same, here i attach de log

Perhaps try reinstalling the fglrx module in synaptic?

Tinchio: dri is disabled for you as well.

Same 100% CPU utilisation problem here, after upgrading from Edgy to Feisty. Problem exists if I leave system for some (long) time, especially when I lock the screen. After coming back I'm able to unlock the screen, the desktop is running, superkaramba widgets are running smoothly, showing 100% CPU util, ktorrent seems to be running smoothly as well (I can see network traffic on one of the widgets). The icons on the desktop are displaying hover effect, but panels are not responding (hidden panels are not showing). Sometimes when I'm leaving for not so long, xorg CPU util. goes back to normal after few seconds of interaction with system. I switched screensaver to "blank screen" from "solar winds", but it didn't help.

Same problem here too...I think that it wappens when i am using azureus( at least this is the reason why i leave the computer open when i am not using it) and a couple of times that i left it whithout usng azureus it hasen't occured.. Next time it happened again i will attach the script

Here it is (this is what you want right???)

Hi,

I'm not suffering from the issue reported in this bug, but I wanted to suggest that this bug gets unmarked as a duplicate of bug #88815. If people are still experiencing problems with Feisty, then it's not related to bug #88815, due to slowdown caused by xcb which has since been fixed (by not building with xcb support).

I'm posting also output of the "ps -eouser,fname,pid,pcpu,pmem" command taken at the moment of 100% CPU utilisation happening (switched to console to do that). I agree with Conn, that this is not the same bug as #88815.

I don't know if this is the same problem, but ever since I upgraded from Edgy to Feisty, every time I try to record in Audacity, my CPU usage goes to 100%, with Xorg being the reason. I never had this problem with Edgy. Otherwise, everything is normal. It is only when I press the record button in Audacity that the problem occurs.

I came and i saw that my cpu was 100% for once more BUT i didn't reboot it.I went out and when i came again the cpu usage was NORMAL....I think that this is pretty important information and i wanted to share it.Also for a little bit more safe restart keep opened and not minimized a terminal window so if it happend again just to write "sudo reboot"(Also the fact that you can still write on an opened terminal is also important no??)

The bug with 100% cpu usage is happening also when working for long time in one window and not switching to another or to the desktop (fullscreen Battle for Wesnoth or fullscreen vmplayer). This one window is active, you can continue to work within it (performance is bad though). Sometimes, when one act fast and switch windows not long after 100% cpu usage starts, everything goes back to normal after few seconds.
This bug is really troublesome.

This doesn't sound like an XCB-related bug, especially since Ubuntu currently isn't using XCB, so I've marked it no longer a duplicate of #88815.

it looks like this is a duplicate of bug 109507 and bug 120347, as well as bug 104481 and bug 51991.
I have exactly the same problem and I haven't found a solution yet, but I will try disabling superkaramba to see if the problem persists. If there is a path for superkaramba that addresses this issue (because according to the bug reports, a lot of people have reported that superkaramba is indeed the problem), that would be ideal.

Disabling superkaramba helped on my machine. sk seems to be the problem.

There are a lot of reasons why the GPU would soft lock (ie. mouse moves, Xorg eating 100% CPU and can be killed remotely), and this bug seemed to be about the binary driver fglrx (and apparently nvidia too). There's not much we can do about those, so I'm just filing this against linux-restricted-modules package.

This package has become obsolete so we're closing out the bug report as WONTFIX.
Thanks for reporting it though!