Bug 242386

Summary: Xorg burns CPU cycles, making desktop sluggish
Product: [Fedora] Fedora Reporter: Chris Rankin <rankincj>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 10CC: chrisspen, hvtaifwkbgefbaei, triage, utmue, vivek.patankar, xjakub
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 05:55:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg config file
none
Xorg log file
none
Xorg.conf for sluggish Xorg. none

Description Chris Rankin 2007-06-03 21:49:47 UTC 
Description of problem:
Simple tasks, such as firefox or switching desktops, make Xorg's CPU usage hit
the roof.

Version-Release number of selected component (if applicable):
FC7, firefox 2.0.0.4, xorg-x11-server-Xorg-1.3.0.0-5

How reproducible:
Very.

Steps to Reproduce:
1. Open a terminal and run top. (My screen resolution is 1680x1050 at 24bpp.)
2. Go to the RedHat bugzilla page and start entering a bug report.
3. Obscure the terminal with firefox.
4. Flick between the terminal and firefox windows.
  
Actual results:
The firefox window is redrawn very, very slowly, and I have a dual 2.66 GHz P4
Xeon, with HT enabled and 2 GB RAM! Also, the Xorg process spikes at > 50% CPU
usage, particularly when I scroll the firefox window using the mouse wheel.

Expected results:
I expect a static webpage to be redrawn a little snappier than that. FC6 was not
this bad.

Additional info:
I'll attach my xorg.conf file, which will reveal that I have a Radeon rv280
graphics card. AIGLX is enabled, but I sure am not using compiz here! Using
compiz is a Jedi training exercise in patience. I thought it was just because I
have a low-end graphics card, but then I tried an Ubuntu Live CD on an old 350
MHz P2 with a Radeon 7000 and that Ubuntu desktop rotated its cube just fine at
1280x1024 resolution!

Firefox is just an easy example. Flicking between alternate desktops is also slow.

There is something *nasty* about this Xorg server.
Comment 1 Chris Rankin 2007-06-03 21:49:47 UTC 
Created attachment 156040 [details]
Xorg config file
Comment 2 Chris Rankin 2007-06-03 21:51:10 UTC 
Created attachment 156041 [details]
Xorg log file
Comment 3 Chris Rankin 2007-06-04 20:58:27 UTC 
This is what pstack says about my Xorg process:

# pstack 3680
#0  0x006c8d1c in memcpy () from /lib/libc.so.6
#1  0xa7a3610b in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#2  0xa7a69747 in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#3  0xa7a6d798 in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#4  0xa7a68cf9 in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#5  0xa79d6161 in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#6  0xa7a5b559 in BitOrderInvert () from /usr/lib/dri/r200_dri.so
#7  0xb7ef7d9d in BitOrderInvert ()
#8  0xb7ebd11c in BitOrderInvert ()
#9  0xb7ebcc0a in BitOrderInvert ()
#10 0xb7ec153c in BitOrderInvert ()
#11 0x0814ef6e in ?? ()
#12 0x0808936a in Dispatch ()
#13 0x080710a5 in main ()

It looks like it's firefox that makes Xorg work particularly hard.
Comment 4 Chris Rankin 2007-06-04 23:48:27 UTC 
More information:

I have managed to get compiz running properly now - a small matter of finding
the correct plugin order. Compiz does run *fairly* well now, although it does
increase CPU usage.

Consider the following scenario, run both with and without compiz enabled:
- Screen resolution at 1680x1050, 24bpp
- Two gnome-terminals, one with 24 lines and running top, the other with 55
lines and running "vi /var/log/Xorg.0.log".
- Firefox is *not* running. Nor is beagle!
- Start at the top of the file, and press <Page Down> until you reach the
bottom. Then keep pressing <Page Up> until you hit the top. Repeat.

With compiz enabled, Xorg's CPU usage while paging through the Xorg.0.log file
hits ~70%. With compiz disabled, Xorg's CPU usage hits ~10%.

In the Module section of my xorg.conf file, I have enabled the "xtrap" module
and disabled the "fbdevhw" module. I don't know if this makes any difference.

BTW This is a 256 MB card, but the Xorg.0.log file says that *half* of that is
inaccessible! So does my card effectively have only 128 MB? Is this a typical
Radeon trick? A hardware limitation, perhaps?
Comment 5 Adam Jackson 2007-06-06 22:27:58 UTC 
The texture-from-pixmap feature that compiz relies on is basically all memcpy
all the time.  Yes, it's going to burn CPU.  We're working on it.

As for the memory size thing:

(II) RADEON(0): Detected total video RAM=262144K, accessible=131072K (PCI
BAR=131072K)

PCI only lets devices map so much address space directly.  The rest is
accessible from the GPU side but not the CPU side.  We do use that memory for
offscreen pixmaps though.
Comment 6 Chris Rankin 2007-06-06 23:52:46 UTC 
> The texture-from-pixmap feature that compiz relies on is basically all memcpy
> all the time.  Yes, it's going to burn CPU.  We're working on it.

Thanks for the reply, but compiz isn't the problem - compiz just makes a bad
situation even worse. After all, Ubuntu 7.04 on my 350 MHz P2 with Radeon 7000
doesn't feel as sluggish when running the desktop effects at 1280x1024, and that
machine must suffer more with memcpy than my 2.66 GHz dual P4 with Radeon 9200.

I'm suspecting that the cause is more likely EXA, despite me accelerating
everything I could find. I am currently running with XAA instead, and firefox
and gnome-terminal are both seem to be redrawing their windows much faster. The
cube is spinning more smoothly too.

As an aside, I have just enabled compiz and it too is behaving a lot better
under XAA than EXA. In fact, it actually feels usuable like this! (I think
Ubuntu uses XAA too.)

I am considering this bug to be about slow redraws and the sluggish response of
the desktop, and I was attributing that to the high CPU usage. (Although the CPU
monitor graph doesn't look anything like as busy under XAA either.)

> PCI only lets devices map so much address space directly.  The rest is
> accessible from the GPU side but not the CPU side.  We do use that memory
> for offscreen pixmaps though.

I'm thinking that me using the "XaaNoOffscreenPixmaps" option would be a bad
idea then, despite this seeming to be common advice for running compiz.
Comment 7 Chris Rankin 2007-06-07 00:16:27 UTC 
There's a bit of "causality violation" in my previous comment. I obviously went
back and added the bit about the cube spinning more smoothly *after* I had
enabled compiz. However, I am currently compiling wine while running compiz, and
the cube is *still* rotating fine, so things really do seem smoother with XAA
rather than EXA.
Comment 8 Vivek J. Patankar 2007-06-24 04:17:30 UTC 
I'd like to add a `me too` here. I use an Acer Aspire 5004 laptop. The graphics
adapter is a SiS 760. The driver used by xorg is `sis`. Symptoms are somewhat
similar to what Chris mentioned earlier. If I try to fetch mail using
thunderbird the CPU utilisation jumps to 30-50% causing the processor to up it's
speed from 800MHz to 1.8GHz. Same happens when I try to send a mail. The reason
why I am linking this to xorg is that at both times the progress bar scrolling
is the only change in the display. This happens when I run xmms too. If I keep
the visualisation mode on the CPU utilisation is around 30% making the laptop
run hotter. With visualisation off the utilisation is 2-4%.
Comment 9 markm 2007-07-04 11:01:11 UTC 
I have a similar problem - sometimes after a few hours of work Xorg eats around
50% of my processor - I can switch off everything and it still remains on a high
level of cpu usage.
Comment 10 Sami Farin 2008-03-25 21:27:15 UTC 
This slowdown happens because of bullshit algorithm(s) in Xorg exa code.

For example, when I use Xorg long enough, redrawing audacious needs five seconds
of CPU time on Pentium D 4 GHz.

These functions need to be improved or redesigned:

ExaOffscreenMarkUsed: O(N) algo for searching areas with state
ExaOffscreenRemovable.
And what's that .. "if (++iter == 10)"... is there a design behind that?

exaOffscreenFree: O(N) algo for deleting an item from a linked list.
Good that Linux Kernel does not have this kind of code, it would otherwise take
a year to startup Xorg.

exaOffscreenAlloc: O(N) algo for searching area with state == ExaOffscreenAvail.

Hey seriously, steal list.h from Linux and put different states in different
lists, and rethink that score thing.  Maybe keep items in RB-tree?



CPU: P4 / Xeon, speed 2797.2 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped)
with a unit mask of 0x01 (mandatory) count 240000
Counted MACHINE_CLEAR events (cycles with entire machine pipeline cleared) with
a unit mask of 0x01 (count a portion of cycles the machine is cleared for any
cause) count 12000
Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus)
with a unit mask of 0x03 (multiple flags) count 60000
Counted RETIRED_BRANCH_TYPE events (retired branches, selected by type) with a
unit mask of 0x1f (multiple flags) count 180000
Counted RETIRED_MISPRED_BRANCH_TYPE events (retired mispredicted branched,
selected by type) with a unit mask of 0x1f (multiple flags) count 6000
samples  %        samples  %        samples  %        samples  %        samples
 %        image name               app name                 symbol name
259730   57.5367  3123     26.6127  31165    63.5683  4265     24.4749  11091  
 44.5905  libexa.so                libexa.so                ExaOffscreenMarkUsed
43878     9.7201  483       4.1159  4053      8.2670  705       4.0457  37     
  0.1488  libexa.so                libexa.so                exaOffscreenFree
41115     9.1080  509       4.3375  3303      6.7372  765       4.3900  1852   
  7.4458  libexa.so                libexa.so                exaOffscreenAlloc
14334     3.1753  3468     29.5526  1179      2.4048  102       0.5853  78     
  0.3136  intel_master_drv.so      intel_master_drv.so      i965_prepare_composite
3360      0.7443  763       6.5019  366       0.7465  64        0.3673  34     
  0.1367  libpixman-1.so.0.9.6     libpixman-1.so.0.9.6    
pixman_compute_composite_region
Comment 11 Chris Spencer 2008-04-12 15:45:16 UTC 
I also have this problem. I first started experiencing it after I switched from
the proprietary ATI driver, to the open source one. Now, simple operations like
entering text in Firefox, or opening the "Application" menu in Gnome take
forever, while Xorg consume 100% CPU.

Could we please increase this ticket's priority to "high"? It's more than mere
"sluggishness". Xorg is so slow as to make simple usage nearly impossible.
Comment 12 Sami Farin 2008-04-12 16:12:33 UTC 
I have used two EXA optimization patches from xserver git since April 1,
patch 1 (commit 93d876891dbba41b920a9a29a5de77f647f43928) removes black magic
from ExaOffscreenMarkUsed,
patch 2 (commit 8074676d2df8d577b443e3fa5e22d7c71c944bd1) optimizes
exaOffscreenAlloc.
They make EXA usable.

These patches are also included in current
Fedora xorg-x11-server-1.4.99.901-21.20080407.
Comment 13 Chris Rankin 2008-04-13 15:00:59 UTC 
This bug is a lot better recently, and I am attributing this to the following
changes:
1) The xf86-video-ati driver for R300 now has full render acceleration.
2) I have added

    Option "MigrationHeuristic" "greedy"

to the Device section of my xorg.conf file. Having said that, it would still be
nice to see some EXA fixes back-patched into the Xorg 1.3 server.
Comment 14 Chris Spencer 2008-04-16 07:48:07 UTC 
Created attachment 302559 [details]
Xorg.conf for sluggish Xorg.

Just for the record, that "MigrationHeuristic greedy" option had no effect
whatsoever on my system. Everything's still slow as ever. Attached is my
xorg.conf.
Comment 15 Chris Rankin 2008-04-16 23:22:30 UTC 
(In reply to comment #14)
> Just for the record, that "MigrationHeuristic greedy" option had no effect
> whatsoever on my system. Everything's still slow as ever.

Try adding the following options to the Device sections:

        Option      "AccelMethod" "EXA"
        Option      "AccelDFS" "on"

By the looks of things, you are using the default acceleration method for both
devices, i.e. XAA rather than EXA.
Comment 16 Chris Spencer 2008-04-17 11:16:09 UTC 
Thanks Chris! That noticeably improved performance.
Comment 17 Chris Spencer 2008-04-18 00:15:06 UTC 
One more note. Those acceleration problems fixed the performance issues in my
first monitor, but worsened performance in my second monitor. Now each flick of
the scroll wheel in Firefox causes Xorg to consume 100% cpu for 15 seconds.
Comment 18 Bug Zapper 2008-05-14 12:46:08 UTC 
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2008-06-17 01:23:35 UTC 
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Sami Farin 2008-10-17 19:26:23 UTC 
1.5.2 is not that much better.
Changing tab in firefox 3 needs 2 s cpu time, of which >90% of CPU time is spent in libexa.so functions exaOffscreenAlloc and exaOffscreenFree.

Because of the nature of the bug, it may be possible to alleviate the problem by restarting X and all the apps every day or so...
But saner options are called for.

In exaOffscreenFree, O(N) algo:
        for (prev = pExaScr->info->offScreenAreas; prev; prev = prev->next)
            if (prev->next == area)
                break;

In exaOffscreenAlloc, O(N) algo:
        /* skip allocated areas */
        if (area->state != ExaOffscreenAvail)
            continue;


profile is not that interesting, each of these two functions burning 34% of the CPU, but gstack says:

#0  0x0000003000cdcb22 in select () from /lib64/libc.so.6
#1  0x0000003005808ac0 in _xcb_conn_wait () from /usr/lib64/libxcb.so.1
#2  0x0000003005809159 in _xcb_out_send () from /usr/lib64/libxcb.so.1
#3  0x0000003005809710 in xcb_send_request () from /usr/lib64/libxcb.so.1
#4  0x0000003002c4c6a1 in _XPutXCBBuffer () from /usr/lib64/libX11.so.6
#5  0x0000003002c4c9ed in _XCBUnlockDisplay () from /usr/lib64/libX11.so.6
#6  0x00000030080060ae in XRenderCompositeTrapezoids () from /usr/lib64/libXrender.so.1
#7  0x000000300a2433d2 in _cairo_xlib_surface_composite_trapezoids () from /usr/lib64/libcairo.so.2
#8  0x000000300a22a4a4 in _cairo_surface_composite_trapezoids () from /usr/lib64/libcairo.so.2
#9  0x000000300a22d9f1 in _composite_traps_draw_func () from /usr/lib64/libcairo.so.2
#10 0x000000300a22cbca in _clip_and_composite () from /usr/lib64/libcairo.so.2
#11 0x000000300a22d54b in _clip_and_composite_trapezoids () from /usr/lib64/libcairo.so.2
#12 0x000000300a22db96 in _cairo_surface_fallback_stroke () from /usr/lib64/libcairo.so.2
#13 0x000000300a22a88b in _cairo_surface_stroke () from /usr/lib64/libcairo.so.2
#14 0x000000300a213c78 in _cairo_gstate_stroke () from /usr/lib64/libcairo.so.2
#15 0x000000300a20e930 in cairo_stroke_preserve () from /usr/lib64/libcairo.so.2
#16 0x000000300a20e961 in cairo_stroke () from /usr/lib64/libcairo.so.2
#17 0x00007f49ad4fc5ca in ?? () from /usr/lib64/gtk-2.0/2.10.0/engines/libnodoka.so
#18 0x00007f49ad4f359d in gdk_rectangle_intersect () from /usr/lib64/gtk-2.0/2.10.0/engines/libnodoka.so
#19 0x00007f49b1e2d699 in moz_gtk_entry_paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#20 0x00007f49b1e2f93b in moz_gtk_widget_paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#21 0x00007f49b1e54e41 in ThemeRenderer::NativeDraw () from /usr/lib64/firefox-3.0.3pre/libxul.so
#22 0x00007f49b1f9500f in NativeRendering () from /usr/lib64/firefox-3.0.3pre/libxul.so
#23 0x00007f49b1f83ed8 in _draw_with_xlib_direct () from /usr/lib64/firefox-3.0.3pre/libxul.so
#24 0x00007f49b1f841fa in cairo_draw_with_xlib () from /usr/lib64/firefox-3.0.3pre/libxul.so
#25 0x00007f49b1f94dde in gfxXlibNativeRenderer::Draw () from /usr/lib64/firefox-3.0.3pre/libxul.so
#26 0x00007f49b1e56bbb in nsNativeThemeGTK::DrawWidgetBackground () from /usr/lib64/firefox-3.0.3pre/libxul.so
#27 0x00007f49b17832b7 in nsCSSRendering::PaintBackgroundWithSC () from /usr/lib64/firefox-3.0.3pre/libxul.so
#28 0x00007f49b1784298 in nsCSSRendering::PaintBackground () from /usr/lib64/firefox-3.0.3pre/libxul.so
#29 0x00007f49b178cbd0 in nsDisplayBackground::Paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#30 0x00007f49b178ce42 in nsDisplayList::Paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#31 0x00007f49b178ceec in nsDisplayClip::Paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#32 0x00007f49b178ce42 in nsDisplayList::Paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#33 0x00007f49b179dff1 in nsLayoutUtils::PaintFrame () from /usr/lib64/firefox-3.0.3pre/libxul.so
#34 0x00007f49b17a539d in PresShell::Paint () from /usr/lib64/firefox-3.0.3pre/libxul.so
#35 0x00007f49b1a85682 in nsViewManager::RenderViews () from /usr/lib64/firefox-3.0.3pre/libxul.so
#36 0x00007f49b1a859cf in nsViewManager::Refresh () from /usr/lib64/firefox-3.0.3pre/libxul.so
#37 0x00007f49b1a86b02 in nsViewManager::DispatchEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#38 0x00007f49b1a7fe62 in HandleEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#39 0x00007f49b1e40941 in nsCommonWidget::DispatchEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#40 0x00007f49b1e39114 in nsWindow::OnExposeEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#41 0x00007f49b1e396e2 in expose_event_cb () from /usr/lib64/firefox-3.0.3pre/libxul.so
#42 0x0000003009d2a1c0 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib64/libgtk-x11-2.0.so.0
#43 0x000000300f80b7ab in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#44 0x000000300f821a28 in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
#45 0x000000300f822fe3 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#46 0x000000300f8236c4 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#47 0x0000003009e2d4be in gtk_widget_event_internal () from /usr/lib64/libgtk-x11-2.0.so.0
#48 0x0000003009d240b2 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#49 0x000000300bc36dcc in gdk_window_process_updates_internal () from /usr/lib64/libgdk-x11-2.0.so.0
#50 0x000000300bc373b9 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0
#51 0x000000300bc373d9 in gdk_window_update_idle () from /usr/lib64/libgdk-x11-2.0.so.0
#52 0x000000300bc1b5ec in gdk_threads_dispatch () from /usr/lib64/libgdk-x11-2.0.so.0
#53 0x000000300d437b43 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#54 0x000000300d43b37d in g_main_context_iterate () from /lib64/libglib-2.0.so.0
#55 0x000000300d43b52c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#56 0x00007f49b1e56fbb in nsBaseAppShell::DoProcessNextNativeEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#57 0x00007f49b1e5721f in nsBaseAppShell::OnProcessNextEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#58 0x00007f49b1f4aabd in nsThread::ProcessNextEvent () from /usr/lib64/firefox-3.0.3pre/libxul.so
#59 0x00007f49b1f10dec in NS_ProcessNextEvent_P () from /usr/lib64/firefox-3.0.3pre/libxul.so
#60 0x00007f49b1e5732d in nsBaseAppShell::Run () from /usr/lib64/firefox-3.0.3pre/libxul.so
#61 0x00007f49b1cf2bfe in nsAppStartup::Run () from /usr/lib64/firefox-3.0.3pre/libxul.so
#62 0x00007f49b15d991f in XRE_main () from /usr/lib64/firefox-3.0.3pre/libxul.so
#63 0x0000000000400e80 in main ()
Comment 21 Sami Farin 2008-10-17 19:30:17 UTC 
Can someone change version to 10 and reopen the bug...
Comment 22 Bug Zapper 2008-11-26 01:54:23 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 Milos Jakubicek 2009-02-08 19:49:47 UTC 
I have exactly the same problem with a laptop where this did NOT occur on F7-F9. After an upgrade to F10, the computer is hardly usable. 

It uses the radeon driver with AIGLX and Composite options set to "on" in xorg.conf (disabling them doesn't take any effect, nor adding the options mentioned in comment #15). 

The smolt profile of that machine is here:
http://www.smolts.org/client/show/pub_d482fdbf-1991-4155-8144-bae766035dd0
Comment 24 Milos Jakubicek 2009-02-16 18:32:20 UTC 
A simple workaround I've found for this is disabling KMS by adding "nomodeset" to the grub command line -- it has some negative sideeffects (no plymouth), but it works, X holds below 30 %, no sound flickering when starting firefox/scrolling pages/chaing tabs, the system is overall faster...
Comment 25 Bug Zapper 2009-11-18 07:52:37 UTC 
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Bug Zapper 2009-12-18 05:55:44 UTC 
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.