Bug 592766 - Certain sites are dead slow (Wolfram Alpha)
Summary: Certain sites are dead slow (Wolfram Alpha)
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-16 20:04 UTC by Kvikende
Modified: 2018-04-11 19:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-28 15:08:53 UTC
Type: ---

Attachments (Terms of Use)
var log messages (513.42 KB, text/plain)
2010-06-16 13:55 UTC, Kvikende
no flags Details
var log messages (513.42 KB, text/plain)
2010-06-16 13:55 UTC, Kvikende
no flags Details
dmesg (122.31 KB, text/plain)
2010-06-16 13:56 UTC, Kvikende
no flags Details
xorg 0 log (86.12 KB, text/plain)
2010-06-16 14:01 UTC, Kvikende
no flags Details
xorg 0 log old (94.17 KB, text/plain)
2010-06-16 14:01 UTC, Kvikende
no flags Details
xorg 1 log (56.69 KB, text/plain)
2010-06-16 14:01 UTC, Kvikende
no flags Details
xorg 1 log old (46.77 KB, text/plain)
2010-06-16 14:02 UTC, Kvikende
no flags Details
xorg 9 log (28.05 KB, text/plain)
2010-06-16 14:02 UTC, Kvikende
no flags Details
xorg 0 vesa (66.74 KB, text/plain)
2010-06-16 21:45 UTC, Kvikende
no flags Details

Description Kvikende 2010-05-16 20:04:13 UTC
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)

How reproducible:

Steps to Reproduce:
1. Go to Wolfram Alpha
2. Search for a math term, for instance xe^x
3. When fully loaded, scroll down.
Actual results:
Extreme slowness, about 1 scroll step per second.

Expected results:
Nice and smooth scrolls.

Additional info:
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

Comment 1 Chad Feller 2010-06-05 04:38:16 UTC
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.

Comment 2 Chad Feller 2010-06-05 04:51:57 UTC
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.)

Comment 3 Kvikende 2010-06-15 11:31:04 UTC
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.

Comment 4 Matěj Cepl 2010-06-16 09:32:55 UTC
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.

Comment 5 Kvikende 2010-06-16 13:55:35 UTC
Created attachment 424458 [details]
var log messages

Comment 6 Kvikende 2010-06-16 13:55:58 UTC
Created attachment 424461 [details]
var log messages

Comment 7 Kvikende 2010-06-16 13:56:55 UTC
Created attachment 424462 [details]

Comment 8 Kvikende 2010-06-16 14:01:02 UTC
Created attachment 424466 [details]
xorg 0 log

Comment 9 Kvikende 2010-06-16 14:01:24 UTC
Created attachment 424467 [details]
xorg 0 log old

Comment 10 Kvikende 2010-06-16 14:01:50 UTC
Created attachment 424469 [details]
xorg 1 log

Comment 11 Kvikende 2010-06-16 14:02:15 UTC
Created attachment 424470 [details]
xorg 1 log old

Comment 12 Kvikende 2010-06-16 14:02:53 UTC
Created attachment 424471 [details]
xorg 9 log

Comment 13 Matěj Cepl 2010-06-16 14:32:43 UTC
Hmm, there seems to be some suspicious stuff in dmesg. Passing to developers.

Comment 14 Matěj Cepl 2010-06-16 15:22:41 UTC
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.

Comment 15 Kvikende 2010-06-16 15:47:15 UTC
I added to xorg.conf:
Section "Device"
	Identifier	"Card0"
	Driver		"vesa"

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.

Comment 16 Matěj Cepl 2010-06-16 16:26:47 UTC
Is your computer somehow memory/CPU constrained? Could we get /var/log/Xorg.0.log from that VESA attempt, please?

Thank you

Comment 17 Kvikende 2010-06-16 21:45:15 UTC
Created attachment 424598 [details]
xorg 0 vesa

Comment 18 Kvikende 2010-06-16 21:46:52 UTC
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.

Comment 19 Ben Skeggs 2010-06-28 06:00:39 UTC
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?

Comment 20 Kvikende 2010-07-28 15:08:53 UTC
I can confirm that this is fixed.

Comment 21 Chad Feller 2010-08-05 04:26:24 UTC
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.

Comment 22 Ben Skeggs 2010-08-05 04:33:53 UTC
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.

Comment 23 Chad Feller 2010-08-05 05:25:01 UTC
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?

Comment 24 Ben Skeggs 2010-08-05 06:18:33 UTC
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.

Comment 25 Chad Feller 2010-08-05 14:21:16 UTC
Ben, fair enough.

Are there plans to support that, or is it not worth the time/effort due to the age of the GPU?

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