Red Hat Bugzilla – Bug 592766
Certain sites are dead slow (Wolfram Alpha)
Last modified: 2018-04-11 15:30:16 EDT
Description of problem:
Certain sites are very slow to scroll. Actually, they are so slow that the pages are unusable. I am not sure if it is Firefox' but it is with Firefox I'm experiencing the slowness.
Version-Release number of selected component (if applicable):
firefox-3.6.3-4.fc14.x86_64 (from rawhide)
Steps to Reproduce:
1. Go to Wolfram Alpha
2. Search for a math term, for instance xe^x
3. When fully loaded, scroll down.
Extreme slowness, about 1 scroll step per second.
Nice and smooth scrolls.
I'm not sure what kind of logs or whatever is necessary.
Smolt profile: http://www.smolts.org/client/show/pub_17931de7-9b80-4aa8-b229-1e3a9796dbc9
I can confirm this in Fedora 13, with Firefox 3.6. This is not an issue in SeaMonkey 2.0 (which is based off of the Firefox 3.5 branch).
The biggest offender for me is actually Gmail. Firefox typically won't do it when Gmail is first opened, but after Gmail has been open for a while and/or multiple tabs are open Gmail scrolling comes to a crawl.
Other browsers: Epiphany, SeaMonkey, and Google Chrome don't suffer from this issue.
Additionally, this is only a problem on my laptop:
Dell Precision M60
Intel(R) Pentium(R) M processor 2.00GHz
VGA compatible controller: nVidia Corporation NV31 [Quadro FX Go700] (rev a1)
older hardware, yes.
However on my workstation:
Sun Ultra 40 M2
2qty. Dual-Core AMD Opteron(tm) Processor 2222
VGA compatible controller: nVidia Corporation G71GL [Quadro FX 3500] (rev a1)
the Firefox slowdown is unnoticeable. So whatever Firefox is doing the newer hardware seems to be able to muscle through it without a noticeable slowdown. (I'm also running Fedora 13 on the workstation, however the x86_64 build.)
I believe this isn't Firefox' fault but the Novueau driver. I opened system watch to see what ate CPU and saw Xorg going to 100 % when I scrolled. I'll change the component to nouveau.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please add drm.debug=0x04 to the kernel command line, restart computer, and attach
* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)
to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 424458 [details]
var log messages
Created attachment 424461 [details]
var log messages
Created attachment 424462 [details]
Created attachment 424466 [details]
xorg 0 log
Created attachment 424467 [details]
xorg 0 log old
Created attachment 424469 [details]
xorg 1 log
Created attachment 424470 [details]
xorg 1 log old
Created attachment 424471 [details]
xorg 9 log
Hmm, there seems to be some suspicious stuff in dmesg. Passing to developers.
Could you try to reproduce this issue using xorg-x11-drv-nv or xorg-x11-drv-vesa drivers? If it is not slow, we could be sure, the problem lies in nouveau driver.
I added to xorg.conf:
and the kernel argument: nomodeset
(screen was filled with artefacts and impossible to use without)
and went to Wolfram Alpha's page about cow milk.
Xorg eats a lot of CPU time when scrolling (aprox. 100 % on one core), but the slowdown isn't as bad as with Nouveau. I am able to use the site.
Is your computer somehow memory/CPU constrained? Could we get /var/log/Xorg.0.log from that VESA attempt, please?
Created attachment 424598 [details]
xorg 0 vesa
The computer runs BOINC so the CPU and some memory are utilised most/all of the time, but it has a quadcore and 4 GiB of ram so it can handle it.
This should actually be fixed in xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13 (http://koji.fedoraproject.org/koji/buildinfo?buildID=179842).
Can you confirm?
I can confirm that this is fixed.
Not fixed for me in:
Certain sites are still dog slow. I mentioned above that gmail is the worst offender, but actually tv.yahoo.com/listings is even worse.. Scroll through there and Xorg is sucking up 99% of the CPU.
Chad, your bug is unrelated. More than likely your browser is doing operations that either can't be accelerated, causing pixmaps to be migrated in/out of vram a lot, or you've run out of vram and under memory pressure.
How is it unrelated? I was having the same symptoms as the original reporter, and I didn't have this problem until finally liberating myself from the proprietary nVidia driver. I've been running Fedora on this machine since FC6, and this is the first install that I haven't had to install the proprietary driver (due to usability issues with nouveau and nv).
Yes, the issue only manifests itself in gecko based browsers - I haven't suffered from this issue in any webkit browser. Nor did I suffer from this issue with FF when I was running the proprietary driver. Are you suggesting that FF is making video calls that nouveau can't accelerate?
It's unrelated because this bug is due to nouveau previously using libwfb for software access to pixmaps on GeForce 8 due to pixmaps being tiled. NV30 has a completely different rendering path.
So yes, I'm suggesting that firefox is doing an operation that we can't/don't accelerate on NV30 hardware.
Ben, fair enough.
Are there plans to support that, or is it not worth the time/effort due to the age of the GPU?