Bug 469378

Created attachment 322092 [details]
PATCH reverting initial text corruption fix.

Note, this bugzilla slowness first showed up with the initial attempt to fix the textmode corruption issues.

I've tried reverting the patch for that (see attachment for a patch which reverts those changes and applies against the latest version).

Unfortunately reverting these changes does not fix the slowness.

I have an r5xx based card and I am not seeing that.
There was and update for xorg-x11-drv-ati to fix a memory leak recently. Are you using -38?

(In reply to comment #2)
> I have an r5xx based card and I am not seeing that.
> There was and update for xorg-x11-drv-ati to fix a memory leak recently. Are
> you using -38?

I'm so lets try to find out whats different between our systems, here are my possible relevant specs:
x86_64
ati x1950 pro (rv570)
nVidia Corporation MCP55 PCI Express bridge

I'll also attach my xorg.log from a run with modesetting.

Oh also possibly highly relevant I have the following in me xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
        Option      "AccelMethod" "EXA"
EndSection

Note the 'Option      "AccelMethod" "EXA"', last I checked that was necessary to get working Xv on r5xx cards. Can you perhaps add that option and see if you can reproduce the slowness then, that would be good to know.

Created attachment 322113 [details]
xorg.log from successfull X start modesetting

Created attachment 322116 [details]
Xorg.0.log

Here is an Xorg.0.log file. I have vm.overcommit = 2. No xorg.conf file.
The card is a FireGL 3400 which appears to be r530 based.

Created attachment 322117 [details]
lspci -vvv output

This should give you a way to compare my hardware to yours.

Created attachment 322119 [details]
Xorg.0.log from EXA try

I tried using EXA and didn't see your symptoms.
Another different I thought of is that I have my display resolution set to 1280 x 1024 in my gnome user profile. I believe that is the native resolution of my monitor.

can you give the xorg-x11-drv-ati-6.9.0-41 that is in koji a go?

(In reply to comment #8)
> can you give the xorg-x11-drv-ati-6.9.0-41 that is in koji a go?

Just did, I'm afraid that does not help.

I had to leave on Friday about the time -41 came out. I haven't seen any problems with it related to this (though I didn't before either). My 9200 worked at home over the weekend and now that I am back at the office my firegl 3400 continues to work fine. I also have the -73 kernel now at the office.

I have an X1950PRO in a dual head setup and am experiencing severe slowness too. One source is from evolution (the new sqlite stuff is excruciatingly slow when coupled with a nfs mounted home directory) It seems like the spinners in the evolution status bar cause Xorg to eat a lot of CPU and brings all desktop interaction to a crawl. I'm running the latest driver/kernel combination (xorg-x11-drv-ati-6.9.0-41.fc10.x86_64 and kernel-2.6.27.4-73.fc10.x86_64) and today am seeing periodic flashes of the screen. I'm also seeing 

[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
[drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM memory quota.

from dmesg. There don't seem to be any errors in the Xorg.0.log file though. I'm currently not using the EXA option (the only options in my xorg.conf file are for setting up the dual screens). (Anyone know how to get the cursor to be drawn on the second screen? That hasn't worked since I got the card last Thursday.)

I'm going to add the EXA option and reboot since even after quitting evolution, things seem slower than usual. Maybe the drm error is non-recoverable.

Created attachment 322604 [details]
/var/log/Xorg.0.log

I can reproduce very well with
xulrunner-1.9.0.2-5.fc10.x86_64
firefox-3.0.2-1.fc10.x86_64
xorg-x11-drv-ati-6.9.0-41.fc10.x86_64
xorg-x11-server-Xorg-1.5.2-10.fc10.x86_64

*** Bug 470026 has been marked as a duplicate of this bug. ***

Can you give 2.6.27.5-88 a go when it lands in koji (before I get it moved into rawhide).

You might want to grab the -42 of ati as well just so I know you are running what I am.

I saw they were out, but I won't be at the desktop with the r530 until Monday and I wasn't seeing the slowness that the others were seeing in any case.
I'll try -42 and maybe the new kernel (it takes a long time to download at home) on my r200 over the weekend. But since modesetting isn't turned on yet for r200s, that won't help much either.

I'm afraid the latest kernel still is painfully slow when using bugzilla. Here is what I'm using:
kernel-2.6.27.5-88.fc10.x86_64
xorg-x11-drv-ati-6.9.0-42.fc10.x86_64
xorg-x11-server-Xorg-1.5.3-1.fc10.x86_64
libdrm-2.4.0-0.21.fc10.x86_64
mesa-libGL-7.2-0.13.fc10.x86_64

Note that I'm not using compositing and I'm enabling EXA in my xorg.conf (I don't know what the default is now a days, but enabling EXA used to be necessary with r5xx cards to get working Xv).

Sorry, I can't test until Monday either.

the kernel.x86_64 2.6.27.5-94.fc10 seems to have PARTIALLY fixed this issue...

Scrolling (for example) in firefox used to be very painful and games (like frozen bubble, so no 3D) where unplayable. With the recent update, it seems to be a lot better :
I can scroll (almost) normally in firefox (though it still takes a huge amount of UC, but it's now fluid).

Ok, so as discussed on IRC have tested a special version of xorg-x11-drv-ati with software fallback debugging enabled.

This results in two types of messages in xorg.log:
1)
RADEONGetDatatypeBpp: Unsupported bpp: 1
RADEONPrepareSolidCP: RADEONGetDatatypeBpp failed

2)
RADEONCheckTexturePOT: NPOT repeating source unsupported (96x96), transform=1

Message 1 happens the most often, but 2 seems to be the cause of the slowdown here. I've "fixed" 2 by replacing:

static Bool RADEONCheckTexturePOT(PicturePtr pPict, Bool canTile)
{
    int w = pPict->pDrawable->width; 
    int h = pPict->pDrawable->height;

    if (pPict->repeat && ((w & (w - 1)) != 0 || (h & (h - 1)) != 0) &&
        !(!pPict->transform && canTile))
        RADEON_FALLBACK(("NPOT repeating %s unsupported (%dx%d), transform=%d\n
                         canTile ? "source" : "mask", w, h, pPict->transform !=

    return TRUE;
}

With:
static Bool RADEONCheckTexturePOT(PicturePtr pPict, Bool canTile)
{
    return TRUE;
}

And now bugzilla is fast again (its also faster without modesetting, but the slowdown caused by this was much bigger with modesetting).

I think given the 96x96 in the message, that this is caused by this background
picture used by bugzilla:
https://bugzilla.redhat.com/skins/contrib/RedHat/global/bkgrnd_greydots.png

Changing the size of this to 128x128 will most likely work around this.

Apparently on my system the fallback caused by this is very very slow when using modesetting, the:
RADEONCheckTexturePOT: NPOT repeating source unsupported (96x96), transform=1

Message only gets printed a few times when doing something with bugzilla, yet the bugzilla page can take up to 3 seconds to respond to things like clicking somewhere.

Changing bugzilla's skin from "RedHat" to "classic" under bugzilla's preferences is another way to workaround this, perhaps this is why not everyone can reproduces this.

I can confirm that I am not using a background image when using bugzilla (or any place else), so that might account for why I am not seeing the problem.

Please try xorg-x11-drv-ati-6.9.0-45 and see if it helps. Its not perfect yet but it should be a lot better.

The problem is a background on bugzilla + zoomed in rendering, which explains why I never saw it.

(In reply to comment #22)
> Please try xorg-x11-drv-ati-6.9.0-45 and see if it helps. Its not perfect yet
> but it should be a lot better.

this seems to be buggy : freezes ALWAYS about 5 min after the boot.

back to xorg-x11-drv-ati-6.9.0-38, doesn't freeze.

(In reply to comment #22)
> Please try xorg-x11-drv-ati-6.9.0-45 and see if it helps. Its not perfect yet
> but it should be a lot better.
> 
> The problem is a background on bugzilla + zoomed in rendering, which explains
> why I never saw it.

Ah, I didn't even known I was using zoom, seems that this is something firefox remembers per site.

Anyways I tried the new version and its better, now it no longer takes 3 seconds to draw the dropdown of the Status selection list, but only 1 second and a bit. Still annoyingly slow though. but disabling the zoom and/or choosing a different theme fixes it.

I'm running the latest kernel-2.6.27.5-113.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-48.fc10.x86_64 and am getting periodic flashes on the first head. It's like the output to the first screen goes out for a second and then comes back. Nothing is logged in dmesg or Xorg.0.log. Things seem a little bit quicker but I seem to notice more random temporary corruption too.

I'm running kernel-2.6.27.5-116.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-51.fc10.x86_64 and I don't get the screen flashes anymore.

OK, so is this bug ready to be CLOSED/RAWHIDE?

(In reply to comment #27)
> OK, so is this bug ready to be CLOSED/RAWHIDE?

No,

A one second delay between clicking on a button and getting the dropdown menu drawn is IMHO not acceptable. I'm not saying that, given the workarounds, this is high priority, but it is not fixed!

No, it's not fixed.

2D games are still very slow (almost unplayable) while they were very fast with fedora 9 (and same hardware).

Xchat with transparency is also very slow.

etc

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

Firefox 3.5 is considerably slow when browsing bugzilla.redhat.com on Fedora 11 x86_64, too. 

Ati mobility x1600 (r5xx), using the default configuration for this card and radeon 6.12.2 driver + modesetting is turned on.

Sometimes the whole screen starts to flicker (not only in the Firefox window) when browsing the site.

(In reply to comment #31)
> Firefox 3.5 is considerably slow when browsing bugzilla.redhat.com on Fedora 11
> x86_64, too. 
> 
> Ati mobility x1600 (r5xx), using the default configuration for this card and
> radeon 6.12.2 driver + modesetting is turned on.
> 
> Sometimes the whole screen starts to flicker (not only in the Firefox window)
> when browsing the site.  

I can second that i am seeing this problem Fedora 11 recent update kernel 
version. My video card is ATI ES1000 

kernel-2.6.30.9-90.fc11.x86_64.rpm
xorg-x11-drv-ati-6.12.2-14.fc11.x86_64.rpm

Can anyone here give me some heads up on this bug, i just want to dig in 
and fix it.

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

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.