(Needs a 3.10.5 kernel) saucy/raring has frequent image corruption (intel, sna)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xf86-video-intel |
Fix Released
|
Medium
|
|||
xserver-xorg-video-intel (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
It seems similar to bug #1144558 which was supposed to be fixed, I was never able to trigger the issue easily in raring but in saucy it's quite easy to see in firefox tab's summary or in chromium's url bar
I'm attaching a screenshot showing the issue
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: xserver-
ProcVersionSign
Uname: Linux 3.9.0-4-generic i686
.tmp.unity.
ApportVersion: 2.10.2-0ubuntu1
Architecture: i386
CompizPlugins: [core,composite
CompositorRunning: compiz
CompositorUnred
CompositorUnred
Date: Tue Jun 11 12:20:23 2013
DistUpgraded: Fresh install
DistroCodename: saucy
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingI
GraphicsCard:
Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Dell Device [1028:040a]
InstallationDate: Installed on 2010-10-09 (975 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: Dell Inc. Latitude E6410
MarkForUpload: True
PccardctlIdent:
Socket 0:
no product info available
PccardctlStatus:
Socket 0:
no card
PlymouthDebug: Error: [Errno 13] Permission non accordée: '/var/log/
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: xserver-
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/30/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A11
dmi.board.name: 0HNGW4
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Latitude E6410
dmi.product.
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.9~
version.libdrm2: libdrm2 2.4.45-2ubuntu1
version.
version.
version.
version.
version.
version.
version.
version.
Related branches
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #19 |
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #20 |
Created attachment 75707
glxinfo -l -t
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #21 |
Created attachment 75708
Screenshot with example of corrupted rendering
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #22 |
I still haven't been able to reproduce this one yet. Do you have a foolproof (and remember just how big a fool I am!) recipe?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #23 |
This issue happens occasionally, but I don't have a 100% reproducible way to show it. One of the most sucessfull attempts to reproduce it is:
1. make all `speed dial` buttons (previews on about:newtab) in Firefox filled with something reasonably heavy, not plain-text pages (on my machine it is a couple of youtube pages, web interface to SAGE, couple of redmines, etc.)
2. close all tabs except one and this last one tab should be about:newtab page
3. middle-click all the previews as fast as you can one by one, so the pages begin to load in background
3. now hit Ctrl+W till you close everything including that about:newtab page where you've started. You shouldn't wait until all pages you've opened on step 3 are loaded.
4. now open about:newtab again and with a good chance some of the preview will be corrupted. Sometimes there is no corruption, but some preview is displayed on the wrong position, for example two different sites share the same preview image.
Another way to reproduce:
1. make at least one `speed dial` button (preview on about:newtab) in Firefox filled with any kind of preview, just any site you want
2. close all tabs except one and this last one tab should be about:newtab page
3. go to http://
4. open about:newtab again and remove any preview image from it by pressing [X]
5. open bookmarks and drag dreamworksanimation bookmark you've made on step 3 into the freed on step 4 place
6. now visit http://
7. close tab and open again about:newtab. The preview for dreamworksanimation should be corupted
Sorry if the descriptions are a bit messy. Also I don't have any other issues with firefox sites rendering, just issues with rendering previews. I wish there was an easier way to reproduce it.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #24 |
I did git bisecting between 2.20.18 and 2.20.19 and the result is this commit:
dc643ef753bcfb6
commit dc643ef753bcfb6
Author: Chris Wilson <email address hidden>
Date: Thu Jan 17 12:27:55 2013 +0000
sna: Apply read-only synchronization hints for move-to-cpu
Signed-off-by: Chris Wilson <email address hidden>
:040000 040000 0f53950ba9a9756
As this bug is not 100% reproducible it could slipped out of my sight during some bisect runs, however it is something to start with. What do you think? Could this sommit lead to the rendering problems I have?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #25 |
There was a related bug, fixed with
commit 19bd005056a2083
Author: Chris Wilson <email address hidden>
Date: Fri Feb 22 12:05:04 2013 +0000
sna: Avoid migrating and making the GPU bo busy prior to mmapping it
References: https:/
Signed-off-by: Chris Wilson <email address hidden>
that I thought was already in 2.21.3 and so you had tested it. It is actually in master, so can you try compiling from git and checking if that fixes the issue?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #26 |
I'll admit to not fully explaining how that prevented the corruption, as the damage should had been migrated and then the kernel should have stalled upon the read... But it did have an effect and prevented a similar issue that bisected to the same commit.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #27 |
(In reply to comment #6)
> It is
> actually in master, so can you try compiling from git and checking if that
> fixes the issue?
I've just tested master and the issue is still there.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #28 |
Created attachment 75871
xf86-video-
With this patch applied on top of xf86-video-
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #29 |
Can you try converting each of those kgem_bo_
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #30 |
Created attachment 75892
Force CPU synchronisation after writes
Another test to try.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #31 |
(In reply to comment #11)
> Created attachment 75892 [details] [review]
> Force CPU synchronisation after writes
>
> Another test to try.
With this patch applied on top of 2.21.3 the problem seems to be fixed.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #32 |
Created attachment 75920
kgem_bo_
(In reply to comment #10)
> Can you try converting each of those kgem_bo_
> kgem_bo_sync__cpu() individually and see if we can narrow it down to one
> particular path?
With this patch on top of 2.21.3 I've hit the bug almost immediately. In this case I've left first kgem_bo_
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #33 |
Created attachment 75921
kgem_bo_
(In reply to comment #10)
> Can you try converting each of those kgem_bo_
> kgem_bo_sync__cpu() individually and see if we can narrow it down to one
> particular path?
With this patch on top of 2.21.3 I was unable to reproduce the bug anymore. In this case I've converted first kgem_bo_
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #34 |
I've looked through all callers to see if I can find one that missed the MOVE_WRITE to no avail. I've double checked the kernel to see if there is a loop hole, again to no avail. So I'm a little bit lost to see where the missed synchronisation is coming from, and I haven't yet thought of a good test to force/catch an error.
In the meantime, I've applied one minor tweak to xf86-video-
commit 60ec35b8d25ecfa
Author: Chris Wilson <email address hidden>
Date: Tue Mar 5 11:14:37 2013 +0000
sna: Be explicit when checking for an idle bo after CPU synchronisation
Do you mind giving that a quick test?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #35 |
Also one other test is to try with the drm-intel-next kernel.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #36 |
(In reply to comment #15)
> I've looked through all callers to see if I can find one that missed the
> MOVE_WRITE to no avail. I've double checked the kernel to see if there is a
> loop hole, again to no avail. So I'm a little bit lost to see where the
> missed synchronisation is coming from, and I haven't yet thought of a good
> test to force/catch an error.
>
> In the meantime, I've applied one minor tweak to xf86-video-
>
> commit 60ec35b8d25ecfa
> Author: Chris Wilson <email address hidden>
> Date: Tue Mar 5 11:14:37 2013 +0000
>
> sna: Be explicit when checking for an idle bo after CPU synchronisation
>
> Do you mind giving that a quick test?
OK, I'll test it later today
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #37 |
(In reply to comment #16)
> Also one other test is to try with the drm-intel-next kernel.
Could you please give me a quick link to their git repo?
Would 3.9-rc1 would be enough?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #38 |
Our upstream is http://
If you are using ubuntu, you can find pre-packaged kernels here http://
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #39 |
Created attachment 76040
Disable read-read optimisations
And one last request, can you please test that this patch as a temporary solution?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #40 |
(In reply to comment #20)
> Created attachment 76040 [details] [review]
> Disable read-read optimisations
>
> And one last request, can you please test that this patch as a temporary
> solution?
This patch also fixes the issue. It was tested on 3.7.10 kernel as well as all previous patches. Now gonna try with drm-intel-next.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #41 |
(In reply to comment #21)
> (In reply to comment #20)
> > Created attachment 76040 [details] [review] [review]
> > Disable read-read optimisations
> >
> > And one last request, can you please test that this patch as a temporary
> > solution?
>
> This patch also fixes the issue. It was tested on 3.7.10 kernel as well as
> all previous patches. Now gonna try with drm-intel-next.
Thanks. In the meantime, I'm going to push the temporary workaround - obviously I still hope to find the real bug.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #42 |
(In reply to comment #16)
> Also one other test is to try with the drm-intel-next kernel.
Ok, just tried out today's drm-intel-next kernel and was unable to reproduce this bug anymore. This sounds like good news.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #43 |
(In reply to comment #23)
> (In reply to comment #16)
> > Also one other test is to try with the drm-intel-next kernel.
>
> Ok, just tried out today's drm-intel-next kernel and was unable to reproduce
> this bug anymore. This sounds like good news.
Oh, wait, I forgot to rebuild xf86-video-intel without patch. Sorry. Will try vanilla now
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #44 |
/o\ Can you confirm that result with vanilla xf86-video-intel?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #45 |
(In reply to comment #25)
> /o\ Can you confirm that result with vanilla xf86-video-intel?
Sorry to disappoint you, but the issue is reproducible with vanilla xf86-video-intel and drm-intel-next.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #46 |
(In reply to comment #22)
> Thanks. In the meantime, I'm going to push the temporary workaround -
> obviously I still hope to find the real bug.
Is there a way I can help? Attach some debug info or test something?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #47 |
(In reply to comment #27)
> (In reply to comment #22)
> > Thanks. In the meantime, I'm going to push the temporary workaround -
> > obviously I still hope to find the real bug.
>
> Is there a way I can help? Attach some debug info or test something?
If you change the define in src/sna/
diff --git a/src/sna/
index ae6d3c1..5edad51 100644
--- a/src/sna/
+++ b/src/sna/
@@ -57,7 +57,7 @@
#define FORCE_INPLACE 0
#define FORCE_FALLBACK 0
#define FORCE_FLUSH 0
-#define FORCE_FULL_SYNC 1 /* https:/
+#define FORCE_FULL_SYNC 0
#define DEFAULT_TILING I915_TILING_X
that restores the buggy behaviour. If you can keep running with that patch and with --enable-debug to check if any assertions are triggered and see how things progress.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #48 |
(In reply to comment #28)
> If you can keep running with that patch
> and with --enable-debug to check if any assertions are triggered and see how
> things progress.
OK, I've did what you've said, powered on and started to watch Xorg.0.log.
The first thing I did was to open Firefox and trigger this issue several times - no output.
Then I've tried to simulate some typical workflow i.e. opened programs I use on a daily basis and do some things inside them like checking mail, browsing a couple of webpages - still no output.
Then I've decided to close them and return to Firefox and again triggered this issue several times and opened a couple of heavy tabs with flash and suddenly caught this:
(EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace
(EE) 1: /usr/bin/X (mieqEnqueue+0x263) [0x5776c3]
(EE) 2: /usr/bin/X (0x400000+0x4fcd4) [0x44fcd4]
(EE) 3: /usr/lib64/
(EE) 4: /usr/bin/X (0x400000+0x7a477) [0x47a477]
(EE) 5: /usr/bin/X (0x400000+0xa5527) [0x4a5527]
(EE) 6: /lib64/
(EE) 7: /lib64/libc.so.6 (ioctl+0x7) [0x3a9bce3437]
(EE) 8: /usr/lib64/
(EE) 9: /usr/lib64/
(EE) 10: /usr/lib64/
(EE) 11: /usr/lib64/
(EE) 12: /usr/bin/X (BlockHandler+0x44) [0x43f224]
(EE) 13: /usr/bin/X (WaitForSomethi
(EE) 14: /usr/bin/X (0x400000+0x3ade2) [0x43ade2]
(EE) 15: /usr/bin/X (0x400000+0x29b5a) [0x429b5a]
(EE) 16: /lib64/libc.so.6 (__libc_
(EE) 17: /usr/bin/X (0x400000+0x29eb1) [0x429eb1]
(EE)
(EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
(EE) [mi] mieq is *NOT* the cause. It is a victim.
[ 8739.251] [mi] Increasing EQ size to 512 to prevent dropped events.
[ 8739.251] [mi] EQ processing has resumed after 64 dropped events.
[ 8739.251] [mi] This may be caused my a misbehaving driver monopolizing the server's resources.
After that I've tried to reproduce this trace again opening same tabs and triggering issue again and again, but without any luck. Is this stack trace useful in any way?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #49 |
Hmm, I expect dmesg to contain a GPU hang and /sys/kernel/
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #50 |
(In reply to comment #30)
> Hmm, I expect dmesg to contain a GPU hang and
> /sys/kernel/
Too bad I turned off my machine later after I've caught that stack trace, so I can't give you the dump of i915_error_state, but I was checking both dmesg and xsession-errors and there was nothing unusual and no signs of error output from i915.
I'll try to catch it again and if I do I'll attach dmesg and dump of i915_error_state here.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #51 |
*** Bug 61610 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #52 |
(In reply to comment #28)
> If you change the define in src/sna/
>
> diff --git a/src/sna/
> index ae6d3c1..5edad51 100644
> --- a/src/sna/
> +++ b/src/sna/
> @@ -57,7 +57,7 @@
> #define FORCE_INPLACE 0
> #define FORCE_FALLBACK 0
> #define FORCE_FLUSH 0
> -#define FORCE_FULL_SYNC 1 /*
> https:/
> +#define FORCE_FULL_SYNC 0
>
> #define DEFAULT_TILING I915_TILING_X
>
> that restores the buggy behaviour. If you can keep running with that patch
> and with --enable-debug to check if any assertions are triggered and see how
> things progress.
I've been running this way ever since you've asked me, but that stack trace was the only one I was able to trigger, though improper rendering happened a lot.
I am positive that when I caught that trace there were no errors in dmesg.
Now, 2.21.4 is out and I will continue trying to catch something, though
since it happens only in firefox maybe there is issue somewhere else?
What versions of firefox, cairo and gtk do you have?
Also I've noticed this message in .xsession-errors whenever I move previews in Firefox:
(firefox:3574): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed
This happens both with FORCE_FULL_SYNC 0 and 1.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #53 |
I've been primarily using iceweasel (based on ff10) with the system cairo as that is many times faster for gfx. But I've also been using the bloated ff from ubuntu and fedora on different systems (and they use the ancient cairo embedded into firefox). There are a lot of differences in cairo between those versions, so it would not surprise me if it was a bug specific to an older cairo. But I've hoped to have seen it by now as well. :|
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #54 |
I've just tested binary Firefox's versions from their site. I've tried latest versions of 16,17,18 and 19 branches and I was able to trigger the issue in all of them.
Will play with cairo versions now, my current cairo is 1.10.2 with some distro patches on top.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #55 |
Just note well that all firefox post version-10 use their builtin version of cairo. In order to use system cairo, firefox needs a patch to remove its reliance upon non-upstreamed API.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #56 |
Tested firefox-19.0.2 with all available versions of cairo from repos: 1.10.2, 1.12.8, 1.12.10, 1.12.12. Issue is reproducible with all versions.
(In reply to comment #36)
> Just note well that all firefox post version-10 use their builtin version of
> cairo. In order to use system cairo, firefox needs a patch to remove its
> reliance upon non-upstreamed API.
Thanks for info, though I am using Gentoo and use Firefox built from sources on my machine and it is distro-patched to link against system-wide cairo so it's fine.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #57 |
Hmmm, that's news to me. Do you have a link to the patches they apply against firefox?
Or a simple test is something like: http://
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #58 |
Also I've noticed that "disable read-read optimisations" patch practically does the same as converting kgem_bo_
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #59 |
(In reply to comment #38)
> Hmmm, that's news to me. Do you have a link to the patches they apply
> against firefox?
http://
> Or a simple test is something like:
> http://
> should be CPU bound in Xorg and not firefox.
Well, I've visited this link and see some spherical thingy made of particles. What should I check?
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #60 |
(In reply to comment #40)
> Well, I've visited this link and see some spherical thingy made of
> particles. What should I check?
Just look at top; For this particular benchmark, it should be ratelimited by the Xorg process not firefox - or better look at sudo perf top, if firefox is hitting pixman functions, it is a bad firefox.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #61 |
Seems like gentoo has the right patch though, it should be fine. Now if only the other distros also used that patch :(
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #62 |
(In reply to comment #42)
> Seems like gentoo has the right patch though, it should be fine. Now if only
> the other distros also used that patch :(
So, should I check top or not? Because I am a bit confused what exactly means
"ratelimited by the Xorg process not firefox". I am building perf right now though.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #63 |
(In reply to comment #41)
> (In reply to comment #40)
> > Well, I've visited this link and see some spherical thingy made of
> > particles. What should I check?
>
> Just look at top; For this particular benchmark, it should be ratelimited by
> the Xorg process not firefox - or better look at sudo perf top, if firefox
> is hitting pixman functions, it is a bad firefox.
When running this demo in firefox `# perf top` says "42% libpixman-
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #64 |
Only if that pixman time is inside firefox and not Xorg... Have gentoo also disabled server-side gradients in cairo?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #65 |
(In reply to comment #45)
> Only if that pixman time is inside firefox and not Xorg...
I am not familiar with this tool. How do I check this?
> Have gentoo also
> disabled server-side gradients in cairo?
Yes, part of changelog:
10 Sep 2010; Samuli Suominen <email address hidden>
+cairo-
Do not use server-side gradients. It hurts performance, and causes bad
rendering on at least nvidia. Bug 336696.
And this patch is still applied on top of cairo version I am running now. Though maintainers added option to disable it in the latest version in tree. It enabled by default though, so I tested this version also with disabled gradients. Should I check without it?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #66 |
Link to the mentioned gradients patch
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #67 |
Yeah, that gradient patch dramatically hurts performance on Nvidia and Intel systems, whilst having little impact on EXA systems. Kill that patch with fire.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #68 |
(In reply to comment #48)
> Yeah, that gradient patch dramatically hurts performance on Nvidia and Intel
> systems, whilst having little impact on EXA systems. Kill that patch with
> fire.
Tested without this patch, but the issue is still presented.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #69 |
What do you think about comment #39? And how can I check if pixman time shown in `perf top` belongs to Xorg or Firefox? (see comment #46)
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #70 |
If you have the ncurses gui, the second column shows you the "comm" i.e. the process name. Similarly in the perf report.
I'm trying to install gentoo to see if that helps (the prospect of a modern ff using system cairo is very appealing).
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #71 |
(In reply to comment #51)
> If you have the ncurses gui, the second column shows you the "comm" i.e. the
> process name. Similarly in the perf report.
Oh, finally, I was able to get it. Yes, that pixman rendering belongs to Firefox process, not Xorg. Though there is somehow no "comm" column in my perf-top, ncurses gui allows to zoom into threads and that's the solution.
> I'm trying to install gentoo to see if that helps (the prospect of a modern
> ff using system cairo is very appealing).
That't nice to hear :) We have a handbook which covers most of the aspects of installation, but if you'll get stuck somewhere feel free to send me an e-mail, I'll be glad to help you.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #72 |
Reading http://
On the positive news though the latest unstable cairo has dropped the buggy gradients patch (unless legacy-drivers is set).
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #73 |
(In reply to comment #53)
> Reading
> http://
> firefox-
> been dropped. Which is a shame.
Well, you've seen the patches applied on top of firefox and support for system cairo is there. Out of curiosity I've run some initial steps of firefox build and here's a bit filtered result:
grep cairo /var/tmp/
* 6009_fix_
--enable-
--enable-
--enable-
--enable-
checking for cairo >= 1.10... yes
checking CAIRO_CFLAGS... -I/usr/
checking CAIRO_LIBS... -lcairo
checking for cairo-tee >= 1.10... yes
checking CAIRO_TEE_CFLAGS... -I/usr/
checking CAIRO_TEE_LIBS... -lcairo
checking for cairo-xlib-xrender >= 1.10... yes
checking CAIRO_XRENDER_
checking CAIRO_XRENDER_
and this is output from already built firefox I am running now:
ldd /usr/lib/
So, system-wide cairo enabled at build time and it is really there as shown by ldd.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #74 |
(In reply to comment #53)
> Reading
> http://
> firefox-
> been dropped. Which is a shame.
You are not seeing thing like "we're enabling system cairo here ..." directly in ebuild because it is done inside mozcoreconf-
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #75 |
(In reply to comment #53)
> Reading
> http://
> firefox-
> been dropped. Which is a shame.
And the last one, you can find sources of eclasses in your $PORTDIR/eclass dir which is most probably /usr/portage/
P.S. sorry for a burst of comments.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #76 |
Ok, I have ff-19 built at last using gentoo ~amd64 on a lowly ilk. It seems to be doing the right thing regarding using system-cairo and server-side gradients. Next step is to piece together enough components to see if I can reproduce the bug.
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #77 |
(In reply to comment #57)
> Ok, I have ff-19 built at last using gentoo ~amd64 on a lowly ilk. It seems
> to be doing the right thing regarding using system-cairo and server-side
> gradients. Next step is to piece together enough components to see if I can
> reproduce the bug.
Ok, tell me what info I should provide and I'll post it.
As s first step, my firefox and xf86-video-intel USE-flags are:
x11-drivers/
USE="dri sna udev xvmc -glamor -uxa"
www-client/
USE="alsa dbus gstreamer jit libnotify minimal (multilib) pgo system-jpeg wifi -bindist -custom-cflags -custom-
CFLAGS=
CXXFLAGS=
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #78 |
I was able to reproduce that stack trace from Xorg log and intel driver is not an issue here at all.
I found out that the cause of this is the fast spinning mouse wheel. I have a mouse with a wheel which can be scrolled like in 'free roam' mode, without that 'clicks', you know. And if I scroll too fast that stack appears. As before dmesg is clean from any i915 errors and no error state was caught. So, that stack is not related to the bug at all.
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #79 |
I'm still using the optimized flushes on all of my machines and have yet to encounter corruption. :|
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #80 |
Well, I am still experiencing this issue even with latest intel driver :(
Are you running Gentoo now? What is your setup? Could you please give me the output of `emerge --info firefox` and `emerge --info xf86-video-intel`?
I haven't tried Firefox 20 yet though. Could it be the issue in Firefox itself?
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #81 |
Same issue with firefox 20 and xf86-video-intel 2.21.5
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #82 |
Hello.
At last, there is some positive dynamic! Though I still from time to time see corrupted rendering of certain elements on some pages, but at least I haven't seen for a while any completely corrupted previews like it was before. Portions of previews could be corrupted, but only those parts which are rendered corrupted while browsing. So now there are no previews consisiting of complete garbage.
(Both previews and pages are rendered via same drawWindow function in firefox as far as I can tell from sources)
Updates that introduced(?) these changes:
libdrm 2.4.43 -> 2.4.44
xorg-server 1.13.1 -> 1.13.4
GTK+ 2.24.16 -> 2.24.17
agg 2.5 -> 2.5-r2 (nothing big, maintainer changed couple of build options; added in the list because I use gnash in Firefox which uses agg, so maybe somehow connected)
There were other updates, but these are the only changes that are possibly related to the effects I see. I was (and currently do) running xf86-video-
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #83 |
That's unexpected - those updates should have had no impact upon this issue. :|
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #84 |
(In reply to comment #64)
> That's unexpected - those updates should have had no impact upon this issue.
> :|
Nevertheless, the overall look and feel in firefox was improved somehow. Now I've updated mesa to 9.1.2 and kernel to 3.9.0 and these positive effects are preserved.
The situation is much better now than it was when I opened this bug: I don't have random huge screen corruptions in firefox both in thumbnails and during normal browsing. Though I can still trigger this issue and get corrupted page preview, it doesn't interfere with browsing. All other applications are unaffected.
Since, things are quite good now, maybe it is a good idea to enable back that optimizations? What do you think? It looks like I am the only one who has this issue:(
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #85 |
Ok, having made a new release, it is time to see if anyone else is seeing this bug:
commit 8e4263705027594
Author: Chris Wilson <email address hidden>
Date: Tue May 21 11:13:03 2013 +0100
sna: Re-enable read-read optimisations
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #86 |
(In reply to comment #66)
> Ok, having made a new release, it is time to see if anyone else is seeing
> this bug:
>
> commit 8e4263705027594
> Author: Chris Wilson <email address hidden>
> Date: Tue May 21 11:13:03 2013 +0100
>
> sna: Re-enable read-read optimisations
Thank you. I'll update this bug with any new info if I notice any changes bad or good.
Sebastien Bacher (seb128) wrote : | #1 |
- screenshot showing the issue Edit (169.5 KiB, image/png)
- BootDmesg.txt Edit (66.2 KiB, text/plain; charset="utf-8")
- BootLog.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (28.2 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (3.6 KiB, text/plain; charset="utf-8")
- DkmsStatus.txt Edit (318 bytes, text/plain; charset="utf-8")
- DpkgLog.txt Edit (1.4 MiB, text/plain; charset="utf-8")
- GconfCompiz.txt Edit (43.8 KiB, text/plain; charset="utf-8")
- LightdmDisplayLog.txt Edit (2.1 KiB, text/plain; charset="utf-8")
- LightdmGreeterLog.txt Edit (17.7 KiB, text/plain; charset="utf-8")
- LightdmGreeterLogOld.txt Edit (12.4 KiB, text/plain; charset="utf-8")
- LightdmLog.txt Edit (9.7 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (14.2 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (906 bytes, text/plain; charset="utf-8")
- MonitorsGlobal.xml.txt Edit (13.4 KiB, text/plain; charset="utf-8")
- MonitorsUser.xml.txt Edit (13.4 KiB, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (3.4 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (316 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (2.2 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (5.7 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (133.4 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (307.5 KiB, text/plain; charset="utf-8")
- UnitySupportTest.txt Edit (622 bytes, text/plain; charset="utf-8")
- XorgLog.txt Edit (169.1 KiB, text/plain; charset="utf-8")
- XorgLogOld.txt Edit (46.2 KiB, text/plain; charset="utf-8")
- Xrandr.txt Edit (14.1 KiB, text/plain; charset="utf-8")
- xdpyinfo.txt Edit (5.0 KiB, text/plain; charset="utf-8")
Sebastien Bacher (seb128) wrote : | #2 |
It doesn't seem to be happening if I use uxa in xorg.conf
Chris Wilson (ickle) wrote : | #3 |
It's the read-read optimisation that was re-enabled. Not sure where the root cause is as reproducing it reliably and quickly is tricky.
Chris Wilson (ickle) wrote : | #4 |
i.e. not even sure if it is not a kernel bug.
Sebastien Bacher (seb128) wrote : | #5 |
I can trigger the bug quite easy in saucy (open a tab in firefox do it almost every time), let me know if I can help testing/providing debug informations
Chris Wilson (ickle) wrote : | #6 |
The corruption you see in the new tab panel happens when that image is generated and stored to disk. It's debugging the corruption as it occurs is the trick.
Chris Wilson (ickle) wrote : | #7 |
My guess is that there is a path with a missing sync point, like this one:
diff --git a/src/sna/
index 69a151c..be73e27 100644
--- a/src/sna/
+++ b/src/sna/
@@ -4861,6 +4861,13 @@ sna_copy_
}
}
+ RegionTranslate
+ ret = sna_drawable_
+ region, MOVE_READ);
+ RegionTranslate
+ if (!ret)
+ goto fallback;
+
if (alu != GXcopy) {
PixmapPtr tmp;
struct kgem_bo *src_bo;
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #87 |
Sebastien Bacher (seb128) wrote : | #8 |
Thanks Chris, I've tried your git commit [1] and it fixes the issue for me
Changed in xserver-xorg-video-intel (Ubuntu): | |
importance: | Undecided → High |
status: | New → Fix Committed |
Launchpad Janitor (janitor) wrote : | #9 |
This bug was fixed in the package xserver-
---------------
xserver-
* sna-make-
(LP: #1189850)
-- Timo Aaltonen <email address hidden> Tue, 11 Jun 2013 20:10:33 +0300
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Fix Committed → Fix Released |
Sebastien Bacher (seb128) wrote : | #10 |
hum, that patch improved things (I don't get the issue on the new tab preview grib when it was consistent before) but I just ran into a similar issue on a merge request url...
Chris Wilson (ickle) wrote : | #11 |
Any chance you can capture a screenshot of it? Or failing that a photograph, and it would be very useful to know if it is not capturable. If you can reproduce it again, you can try FORCE_FULL_SYNC again, that would identify whether it is the same issue.
Chris Wilson (ickle) wrote : | #12 |
I remembered another path that reads from a source CPU pixmap that made a few presumptions about coherency, so please also test with 15b92c9.
Simon K (octav14n) wrote : | #13 |
I'm also getting this bug from time to time (it's gotten better with this #9 update though).
Screenshot is attached.
Before I even got this "jittery"
Is my screenshot showing a result of this bug? Or do I have to open a new one?
Btw. Firefox seems to swap the images randomly? The YouTube-Preview is actually the same Preview as "heise" is using?! Is this a separate bug?
Simon K (octav14n) wrote : | #14 |
Chris Wilson (ickle) wrote : | #15 |
The newtab looks like this bug, and image swapping is the same (the timing was just right to get a recognisable image of the same size).
Sebastien Bacher (seb128) wrote : | #16 |
@Chris: I will take a screenshot if that happen again
I'm running an update with http://
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #88 |
(In reply to comment #68)
> It's back:
> https:/
> 1189850
Thanks for the link. I've tried today's xf86-video-intel git with the commit which is marked as a solution via link you provided. I can confirm that I was unable to reproduce this issue, but I cannot say for sure as with recent changes this bug on my machine apperars much more rarely than before. It can reappear later, but I hope it won't. I'll provide any new info here if any.
Sebastien Bacher (seb128) wrote : | #17 |
- corrupted image screenshot Edit (23.5 KiB, image/png)
hum, it worked great for the whole day today, until now when I ran into that
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Fix Released → Triaged |
Sebastien Bacher (seb128) wrote : | #18 |
sorry, ignore the previous comment, I was running with "#define FORCE_FULL_SYNC 1", that seems a different issue
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
tags: | added: corruption |
Sebastien Bacher (seb128) wrote : Re: saucy has frequent image corruption (intel, sna) | #89 |
ok, new update ... sorry my testing the other day was incorrect, I had the FORCE_FULL_SYNC define set from a previous testing. Using git master from intel I still see a frequent corruption on e.g the new tab screen :-(
Chris Wilson (ickle) wrote : | #90 |
Sebastien, once 2.21.10 hits saucy, can you please let me know how we are faring here? And please include the latest steps to trigger the bug.
Chris Wilson (ickle) wrote : | #91 |
kernel commit 22fd5ca947b5890
Author: Chris Wilson <email address hidden>
Date: Fri Jun 28 16:54:08 2013 +0100
drm/i915: Only clear write-domains after a successful wait-seqno
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Triaged → Fix Committed |
In freedesktop.org Bugzilla #61628, Chris Wilson (ickle) wrote : | #92 |
commit 22fd5ca947b5890
Author: Chris Wilson <email address hidden>
Date: Fri Jun 28 16:54:08 2013 +0100
drm/i915: Only clear write-domains after a successful wait-seqno
In the introduction of the non-blocking wait, I cut'n'pasted the wait
completion code from normal locked path. Unfortunately, this neglected
that the normal path returned early if the wait returned early. The
result is that read-only waits may return whilst the GPU is still
writing to the bo.
Fixes regression from
commit 3236f57a0162391
Author: Chris Wilson <email address hidden>
Date: Fri Aug 24 09:35:09 2012 +0100
drm/i915: Use a non-blocking wait for set-to-domain ioctl
Signed-off-by: Chris Wilson <email address hidden>
Bugzilla: https:/
Cc: <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #93 |
This bug just reappeared with xf86-video-
Changed in xserver-xorg-video-intel: | |
status: | Confirmed → Fix Released |
In freedesktop.org Bugzilla #61628, Coacher (itumaykin-deactivatedaccount) wrote : | #94 |
(In reply to comment #70)
> commit 22fd5ca947b5890
> Author: Chris Wilson <email address hidden>
> Date: Fri Jun 28 16:54:08 2013 +0100
>
> drm/i915: Only clear write-domains after a successful wait-seqno
>
> In the introduction of the non-blocking wait, I cut'n'pasted the wait
> completion code from normal locked path. Unfortunately, this neglected
> that the normal path returned early if the wait returned early. The
> result is that read-only waits may return whilst the GPU is still
> writing to the bo.
>
> Fixes regression from
> commit 3236f57a0162391
> Author: Chris Wilson <email address hidden>
> Date: Fri Aug 24 09:35:09 2012 +0100
>
> drm/i915: Use a non-blocking wait for set-to-domain ioctl
>
> Signed-off-by: Chris Wilson <email address hidden>
> Bugzilla: https:/
> Cc: <email address hidden>
> Signed-off-by: Daniel Vetter <email address hidden>
Yes, this commit fixes the issue for me (on 3.10 kernel with this patch only).
Thanks a lot for your help!
Jordan Dawson (x9a3k) wrote : Re: saucy has frequent image corruption (intel, sna) | #95 |
I've also been experiencing this exact issue on xubuntu 13.04. I hadn't ever seen it until 13.04.
summary: |
- saucy has frequent image corruption (intel, sna) + (Needs 3.10.2) saucy has frequent image corruption (intel, sna) |
summary: |
- (Needs 3.10.2) saucy has frequent image corruption (intel, sna) + (Needs a 3.10.3 kernel) saucy has frequent image corruption (intel, sna) |
Eugene San (eugenesan) wrote : Re: (Needs a 3.10.3 kernel) saucy/raring has frequent image corruption (intel, sna) | #96 |
I suggest applying same patch in Raring.
summary: |
- (Needs a 3.10.3 kernel) saucy has frequent image corruption (intel, sna) + (Needs a 3.10.3 kernel) saucy/raring has frequent image corruption + (intel, sna) |
tags: | added: raring |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Fix Committed → Fix Released |
Alan Pope 🍺🐧🐱 🦄 (popey) wrote : | #97 |
- IMG_1763.JPG Edit (782.5 KiB, image/jpeg)
I'm experiencing this bug (or something very similar) on my X220, and with bug 1211754 seeming to trigger it about every 10-15 mins, it's pretty annoying. I'm running 3.10.3-
See photo attached.
Chris Wilson (ickle) wrote : | #98 |
That looks like a different bug - the invalid fence after resume.
summary: |
- (Needs a 3.10.3 kernel) saucy/raring has frequent image corruption + (Needs a 3.10.5 kernel) saucy/raring has frequent image corruption (intel, sna) |
Sebastien Bacher (seb128) wrote : | #99 |
(just as a follow up some time later, now that the updated version landed in saucy, things seem to work great, I've not seen any corruption issue recently)
Created attachment 75706
lspci -vvv
Hello.
Since I've upgraded from 2.20.18 version of intel driver page previews in Firefox are rendered improperly (see attached screenshot). Tested versions of intel driver are 2.20.{18,19} and 2.21.{0,2,3}, Firefox's versions are 17.0-19.0. I don't think it is a Firefox issues it is completely gone when downgrading back to 2.20.18.
My system is Gentoo amd64, currently with latest Firefox and intel driver. My current kernel version is 3.8 and it is vanilla. I am using SNA acceleration.
If there is any additional info that would be helpful I am ready to provide it.