Bug 592766

Summary: Certain sites are dead slow (Wolfram Alpha)
Product: [Fedora] Fedora Reporter: Kvikende <kvikende>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: airlied, ajax, bskeggs, cfeller, gecko-bugs-nobody, mcepl
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-28 15:08:53 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
var log messages
none
var log messages
none
dmesg
none
xorg 0 log
none
xorg 0 log old
none
xorg 1 log
none
xorg 1 log old
none
xorg 9 log
none
xorg 0 vesa none

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)
xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64

How reproducible:
Always

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).

firefox-3.6.3-4.fc13.i686
xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.i686

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]
dmesg
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"
EndSection

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:

xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.i686

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?