| Summary: | X busyloops when huge image in firefox | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Pekka Paalanen <ppaalanen> | ||||||||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | ||||||||||||||||
| Version: | git | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 16389 [details]
kernel log with debug=1
Created attachment 16390 [details]
gdb session
This is a gdb session recorded on a serial console.
For many times I interrupt X while it is spinning and print the backtrace.
There's a disassembly of nouveau_notifier_wait_status.
I set breakpoints to NVUploadToScreen and NVDownloadFromScreen to see what kind of calls they get.
Looks like it is migrating a big pixmap a lot. w=1703, h=3000 are probably the original dimensions of the image I used to trigger the problem this time.
During the dozens of calls to NVUploadToScreen, the firefox window does not show any redrawing. After something like 5 mins running, the window updates instantly, and I can re-trigger the freeze by doing anything that would expose a piece of the huge image.
Hmm, I just noticed a pattern there:
NVUploadToScreen (pDst=0x2ba0cf4db010, x=0, y=0, w=1703, h=3000
NVUploadToScreen (pDst=0x1314020, x=0, y=0, w=494, h=1315
NVUploadToScreen (pDst=0x2ba0cf4db010, x=0, y=0, w=1703, h=3000
NVUploadToScreen (pDst=0x1314020, x=0, y=0, w=495, h=1315
NVUploadToScreen (pDst=0x2ba0cf4db010, x=0, y=0, w=1703, h=3000
NVUploadToScreen (pDst=0x1314020, x=0, y=0, w=496, h=1315
NVUploadToScreen (pDst=0x2ba0cf4db010, x=0, y=0, w=1703, h=3000
NVUploadToScreen (pDst=0x1314020, x=0, y=0, w=497, h=1315
See the width of the second pixmap.
Created attachment 16391 [details]
xorg.conf
MigrationHeuristic was not set in my xorg.conf. Setting it to "greedy" seems to make the problem go away.
Created attachment 16393 [details]
X org log EXA fallback instrumentation
Includes additional instrumentation for CheckTexture and CheckBuffer.
Created attachment 16408 [details] [review] Only migrate in source pixmap region needed for CopyNtoN Does this xserver patch help? Option "EXAOptimizeMigration" might help in addition. Michel, I applied your patch, and it indeed makes the freeze period drop from 5 minutes to just less than 1 minute. Then, adding EXAOptimizeMigration makes the freezing go away, I don't have to wait for it to unfreeze anymore. There were some comments on #nouveau that the braindead invocations of NVUploadToScreen might be a Firefox 2 feature. commit 3baf3b42e079b4e7b61c1e20df305db0724d21f8 Author: Michel Dänzer <michel@tungstengraphics.com> Date: Sat May 24 20:01:21 2008 +0200 EXA: Specify region used for source pixmap migration in exaCopyNtoN. Avoids excessive migration overhead in some pathological cases. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 16388 [details] Xorg log When a huge image, e.g. 1500x3000 pixels, is shown in Firefox, any rendering action related to that image freezes firefox for 5-10 minutes. During that time X is eating all CPU, spending 30% in user space and 70% in kernel due to GetTimeInMillis(). Xorg-server xorg-server-1.3.99.0-1538-gefa65a0 xf86-video-nouveau ae574ec7d930d8708e4dd9d1d47558666019afe5 DRM kernel modules drm-2.3.0-1229-g43b224f All of them around 5.5.2008. nouveau.ko is patched to make AGP init fail, since DFS is broken for me. To me DRM and Xorg logs show nothing out of the ordinary.