This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 469378 - bugzilla in firefox unbearably slow (r500 / x1950)
bugzilla in firefox unbearably slow (r500 / x1950)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Triaged
: 470026 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-31 11:16 EDT by Hans de Goede
Modified: 2009-12-18 01:42 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:42:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
PATCH reverting initial text corruption fix. (2.83 KB, patch)
2008-10-31 11:24 EDT, Hans de Goede
no flags Details | Diff
xorg.log from successfull X start modesetting (112.30 KB, text/plain)
2008-10-31 14:28 EDT, Hans de Goede
no flags Details
Xorg.0.log (117.22 KB, text/plain)
2008-10-31 14:50 EDT, Bruno Wolff III
no flags Details
lspci -vvv output (46.18 KB, text/plain)
2008-10-31 14:51 EDT, Bruno Wolff III
no flags Details
Xorg.0.log from EXA try (114.51 KB, text/plain)
2008-10-31 15:13 EDT, Bruno Wolff III
no flags Details
/var/log/Xorg.0.log (117.96 KB, text/plain)
2008-11-05 11:33 EST, Matěj Cepl
no flags Details

  None (edit)
Description Hans de Goede 2008-10-31 11:16:19 EDT
Description of problem:
-ati r500 (x1950) fully up2date rawhide + latest kernel and X stuff from koji
-with modesetting

When using bugzilla in firefox things become very slow. So slow that if I click on the status drop down to go from new to assigned for example, it takes more then 3 seconds for the dropdown to show, and then after clicking it takes quite long for it to disappear too (not timed, in the second range again).
Comment 1 Hans de Goede 2008-10-31 11:24:48 EDT
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.
Comment 2 Bruno Wolff III 2008-10-31 12:06:44 EDT
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?
Comment 3 Hans de Goede 2008-10-31 14:23:41 EDT
(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.
Comment 4 Hans de Goede 2008-10-31 14:28:05 EDT
Created attachment 322113 [details]
xorg.log from successfull X start modesetting
Comment 5 Bruno Wolff III 2008-10-31 14:50:51 EDT
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.
Comment 6 Bruno Wolff III 2008-10-31 14:51:44 EDT
Created attachment 322117 [details]
lspci -vvv output

This should give you a way to compare my hardware to yours.
Comment 7 Bruno Wolff III 2008-10-31 15:13:14 EDT
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.
Comment 8 Dave Airlie 2008-10-31 17:03:09 EDT
can you give the xorg-x11-drv-ati-6.9.0-41 that is in koji a go?
Comment 9 Hans de Goede 2008-11-02 04:24:47 EST
(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.
Comment 10 Bruno Wolff III 2008-11-03 11:45:56 EST
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.
Comment 11 Thomas J. Baker 2008-11-04 10:39:44 EST
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.
Comment 12 Matěj Cepl 2008-11-05 11:33:55 EST
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
Comment 13 Matěj Cepl 2008-11-07 18:20:04 EST
*** Bug 470026 has been marked as a duplicate of this bug. ***
Comment 14 Dave Airlie 2008-11-07 23:58:37 EST
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.
Comment 15 Bruno Wolff III 2008-11-08 00:47:11 EST
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.
Comment 16 Hans de Goede 2008-11-08 07:17:58 EST
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).
Comment 17 Thomas J. Baker 2008-11-08 11:41:35 EST
Sorry, I can't test until Monday either.
Comment 18 Florent Le Coz 2008-11-12 17:16:04 EST
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).
Comment 19 Hans de Goede 2008-11-13 06:37:29 EST
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.
Comment 20 Hans de Goede 2008-11-13 06:42:28 EST
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.
Comment 21 Bruno Wolff III 2008-11-13 08:18:11 EST
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.
Comment 22 Dave Airlie 2008-11-14 15:30:06 EST
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.
Comment 23 Florent Le Coz 2008-11-14 17:12:39 EST
(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.
Comment 24 Hans de Goede 2008-11-17 08:40:52 EST
(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.
Comment 25 Thomas J. Baker 2008-11-17 15:18:05 EST
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.
Comment 26 Thomas J. Baker 2008-11-18 14:08:40 EST
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.
Comment 27 Matěj Cepl 2008-11-19 07:06:16 EST
OK, so is this bug ready to be CLOSED/RAWHIDE?
Comment 28 Hans de Goede 2008-11-19 07:18:44 EST
(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!
Comment 29 Florent Le Coz 2008-11-24 06:03:18 EST
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
Comment 30 Bug Zapper 2008-11-25 23:33:16 EST
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 31 Miro Hadzhiev 2009-06-13 09:02:25 EDT
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.
Comment 32 Harshavardhana 2009-11-06 03:03:47 EST
(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.
Comment 33 Bug Zapper 2009-11-18 03:43:05 EST
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 34 Bug Zapper 2009-12-18 01:42:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.