Red Hat Bugzilla – Bug 157651
xorg X x11 very slow on fast machine while idel
Last modified: 2007-11-30 17:11:06 EST
Description of problem:
This is a 2.8ghz P4 (HT enabled) with 1gb dual-channel ram and 64mb geforce mx
video card. This machine has been a top performer with FC3, both with and
without the proprietary nvidia drivers. So there are no problems with the
hardware. I am running FC4test3 with the latest kernel 1290smp and 'X' is using
50% cpu when I have no applications running, thats with gnome. NB, this high CPU
usage does not seem to happen with kernel 1286smp. This seems to manifest itself
when swapping virtual desktops with the pager, it sometimes takes 1.5 - 2
seconds to change to a window that has for example thunderbird open.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.login to gnome with 1290smp kernel
2. watch top
3. observe high CPU usage
4. swap virutal dekstops and see the noticeable delay (eg 2 seconds)
slow swapping of virtual desktop.
when I tried to 'strace -p $PID_OF_X' the machine hung hard.
I've since upgraded (via yum) to;
still the problem persists.
FYI - this machine dual boots XP-SP2 (ugh!) and there are no noticeable
performance issues with XP.
For all of the following tests, uninstall any Nvidia proprietary drivers
you may have installed currently, and reinstall the latest xorg-x11
packages from fedora development. This is a critical requirement, as
Nvidia's binary drivers overwrite Red Hat supplied files, and we do not
support proprietary drivers. Just switching to "nv" driver does not
restore the Red Hat supplied files.
After doing this, run: system-config-display --reconfig
This will configure your server to use the "nv" driver. Do not modify
the generated config file, or enable/disable any other X server configuration
options. Start the server to ensure it works. Then test it with your normal
desktop setup and reproduce the problem. If you can reproduce it still,
attach your X server log file and config file as individual uncompressed
file attachments. Then perform the following diagnostic tests as well
to help narrow the problem down:
Does it happen in KDE also? Run "switchdesk KDE" and restart the X server
Does it happen in a minimal X enviroment too? Run "init 3" to switch
to runlevel 3, then create a ~/.xinitrc file containing the lines:
Start up the X server by using "startx" now, and it should invoke the
xinitrc instead of your standard GNOME or KDE desktop. Run your apps
from the xterm in the background and report if the problem still exists.
Does it happen only with smp kernel, or also with up kernel? Please boot
into the UP kernel to test. If using a machine with hyperthreading or
dual core, pass appropriate commandline options to kernel to disable HT,
Did this problem start to occur after upgrading to a specific kernel?
What happens if you downgrade to a previous kernel, or to the latest
FC-3 update kernel?
> strace -p $PID_OF_X' the machine hung hard.
More likely what happened, is that you ran strace from a terminal
displaying on the running X server, which will not work. The proper
way to debug/strace/ltrace/etc. the X server, is to log into the
machine over the network via ssh from a different machine, and run
strace on the X server process.
You can not gdb/strace/ltrace the X server from a terminal displaying
on that same X server. It must be from another machine, or from a
VC or serial console or else it causes an n'th complexity binary loop
cascade scenario to occur.
>FYI - this machine dual boots XP-SP2 (ugh!) and there are no noticeable
>performance issues with XP.
Windows XP results are pretty much irrelevant.
Please update the report to indicate the status of all of the above tests.
Setting status to "NEEDINFO", awaiting results of all above diagnostic
tests, and requested file attachments.
I have *not* installed the nividia driver, this is a vanilla FC4T3. I was just
mentioning the fact that the hardware has no issue, thats also the reason that I
mentioned XP, which I think is relevant because it proves there is nothing wrong
with the hardware !
KDE shows the same behaviour, especially when swapping virtual desktops for
example when changing to a windows with thunderbird running.
I already mentioned that going back to 1286 kernel does not get rid of the
problem but does drop the CPU idling usage.
I'll try UP kernel.
Created attachment 114450 [details]
>I have *not* installed the nividia driver, this is a vanilla FC4T3.
From comment #1:
>video card. This machine has been a top performer with FC3, both with and
>without the proprietary nvidia drivers.
You've indicated in the initial report, quoted above, that you have tested
it both with and without the Nvidia proprietary drivers. As such, it is my
duty to inform you that you must remove the nvidia drivers *if* they are
installed, and reinstall our official packages to replace the files nvidia's
driver wipes out, so that the tests I asked you to perform are being done
with our actual supplied X server modules, and not with some of Nvidia's
My comment was informational only - not accusational. Please take it as
>I was just mentioning the fact that the hardware has no issue, thats also
>the reason that I mentioned XP, which I think is relevant because it
>proves there is nothing wrong with the hardware !
You already mentioned in the initial comment:
>So there are no problems with the hardware.
So the hardware's reliability was never a question to begin with really.
Technically, wether or not something happens to work in Windows XP,
generally is not really important, because the hardware is programmed
very differently in Windows versus in Linux. It's even possible to have
hardware failures that only cause a problem in one OS or the other,
depending on the nature of the problem, and how the given OS programs
the hardware (wether the problem affects the usage of the hardware or
not). So, it doesn't "prove" anything really. But again, the reliability
of your hardware is not in question. I'm just pointing that out.
I'd like to confirm something just to be 100% certain. Using the "nv"
open source driver, without having the proprietary drivers installed
at all, and having updated to the latest xorg-x11 for FC3, you are
claiming that this combination (FC-3 + "nv") works fine, but when you
use FC4test3, with the latest FC devel updates including kernel,
you are experiencing these performance problems?
That is my current understanding. What we need to do now, is narrow
down what might be the cause of this performance problem. It sounds
to me like it would be something kernel related, rather than a problem
with xorg-x11, in particular because you say it occurs with both the
open source and closed source drivers. The Xorg in FC4 and FC3 right
now are almost identical, which also makes me think it's more likely
to be a kernel issue.
After doing the above tests I suggested in previous comments, and
supplying all of the files requested, including the config file,
etc. - another test that would be useful, is if using FC4test3,
if you could download the latest FC3 updates for xorg-x11 and
downgrade the entire set of xorg-x11 rpms to FC3's xorg and try
that. Use "rpm -Uvh --oldpackage *.rpm" with the FC3 rpms to
perform the downgrade.
If the FC3 xorg causes the performance problem to go away, then it
is possible the FC4 xorg has regressed in some way, and we can explore
that. If however, the FC3 xorg running in FC4test3 suffers the same
performance problems as the FC4 xorg, but it worked fine in FC3, then
I think it's safe to conclude that the problem is almost certainly
kernel related in some way, which was my impression all along.
Please test the rest of what was asked above, and supply _all_ files
requested as they're vital in our diagnosis. Also test my recent
requests, and provide feedback. That will help us to have a speedy
diagnosis and hopefully be able to resolve the problem ASAP.
Setting status back to "NEEDINFO", and awaiting X server config file,
log file from each session attempt, lsmod output, and /var/log/messages
from the last system boot onward, as well as status updates from
each troubleshooting request above.
Thanks in advance.
Bug lacks sufficient information to diagnose the root cause. Setting
status to "CANTFIX".
If the problem persists in the latest version of Fedora Core with all
updates installed, please report the issue directly to X.Org by filing
a bug report at http://bugs.freedesktop.org in the "xorg" component.