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): xorg-x11-6.8.2-30 How reproducible: always 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) Actual results: slow swapping of virtual desktop. Expected results: Additional info: when I tried to 'strace -p $PID_OF_X' the machine hung hard.
I've since upgraded (via yum) to; 2.6.11-1.1305_FC4smp xorg-x11-6.8.2-31 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 to test. 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: #!/bin/bash xterm 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, etc. Any change? 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.
Information; 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 ! Results; 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] Xorg log
>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 replacement modules. My comment was informational only - not accusational. Please take it as such. >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.