Not as silly a bisect as you might think - I did throw a side-effect into that patch to also try and avoid unnecessary migrations. I'm in the middle of a kernel bug right now,

Can you attach your Xorg.0.log (because I am nosy), and describe which window you open? Heck if you get really bored, another of your famous videos :)

Another thing to check is whether other ff (particular those build with system-cairo) are affected.

Also check kernel version (Xorg.0.log).

Created attachment 82569 [details]
xorg log file

I wouldn't dare if you hadn't asked:  http://youtu.be/2ZFbrOzK5zw ;)

I am running linux-3.10rc7 + your drm patch.

just tested, issue reproduceable with official FF22 build as well as the FF build shipped with feodra-19.

What the...

Ok, that is a little more obvious than I was expecting. I hadn't see anything like that so was expecting some subtle corruption dependent on a precise sequence of steps and applications.

Ok, I don't think this is the same bug - but if you do get the opportunity to test with 3.11-rc2 or drm-intel-nightly, that would be much appreciated.

Ok, reminds me of the 8192+ errors.

Ok, I'll test 3.11rc2 as soon as fedora rawhide builds are available.

Indeed, I get the same bisect as you do. But I think, having experimented with adjusting each chunk, that it is just changing the placement of an operation and so hitting an underlying bug.

The active ingredient in that patch is that we defer the pixmap migration until after we check whether the BLT unit can handle the operation. In this case, it cannot so we then try with the RENDER unit - the difference now is that the source and destination pixmaps are both categorised as being on the CPU. Given that, we prefer to do the operation on the CPU.

But it all should still be rendered correctly...

Clemens can you try this little hack to see if it helps your system:

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 77233cd..c84ca92 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -62,7 +62,7 @@
 
 #define DEFAULT_TILING I915_TILING_X
 
-#define USE_INPLACE 1
+#define USE_INPLACE 0
 #define USE_WIDE_SPANS 0 /* -1 force CPU, 1 force GPU */
 #define USE_ZERO_SPANS 1 /* -1 force CPU, 1 force GPU */
 #define USE_CPU_BO 1


So far I can only reproduce this on SNB. And am quite baffled. Everytime I think I have a lead, it unravels.

Jap, setting USE_INPLACE to 0 makes the issue disappear here ...

Clemens, are your machines reasonably similar in sw config? Can you easily check whether you see this on any other machine? I'm still only seeing it on the one Fedora SNB I have, which is concerning.

I wasn't able either to reproduce it on gen4 with an identical sw config as on my SNB laptop

sorry, ment gen5 (the i540M)

Ok, the issue seems to rely on the prehistoric cairo used by mozilla.

doesn't the firefox build shipped with Fedora use the system's libcairo?
I can reproduce it with official as well as fedora-builds on SNB.

No, fedora is still using mozcairo and haven't noticed that mozilla finally got around to making system-cairo functional again. (Debian and gentoo have been patching back system-cairo support into their versions.)

could it be that they switched back to system-cairo with F19?
I can't find anything relating to mozcairo on my system and /usr/lib64/xulrunner/libxul.so links /lib64/libcairo.so.2.

It's statically linked in, I can tell it's an old cairo as I recognise the sequence of XRender requests. :)

convinced ;)

*** Bug 67073 has been marked as a duplicate of this bug. ***

Note that the issue is masked by:

commit fb058de4e617d7e5058674859993ec635a8d779e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jul 18 13:37:12 2013 +0100

    sna: Treat a source with a CPU bo as being attached.

And then requires

diff --git a/src/sna/gen6_render.c b/src/sna/gen6_render.c
index 9b45d79..5885af3 100644
--- a/src/sna/gen6_render.c
+++ b/src/sna/gen6_render.c
@@ -1955,6 +1955,7 @@ has_alphamap(PicturePtr p)
 static bool
 need_upload(PicturePtr p)
 {
+	return true;
 	return p->pDrawable && unattached(p->pDrawable) && untransformed(p);
 }
 

to reproduce.

I've just bumped the kernel up to the lastest -nightly and the corruption is gone.

I see it with 3.10.

Another page which triggers it: http://pygments.org/docs/lexers/

This is a kernel bug, I think should be resolved by 3.10.5.

confirming, 3.10.5 works :) thanks.