It would also be worthwhile testing with --enable-debug=pixmap

I think I can reproduce the scrolling corruption using ivb + kwin (xrendr compositing + native) + blt. Will pursue.

Found one issue on the hunt for the scrolling corruption. Not sure if this is as relevant for 855gm, but it is worth testing:

commit 53c1faa5093f8a0c969e3ebe9f27ee1ce5137e14
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 11 07:59:41 2014 +0100

    sna: Mark the GPU as all damaged when discarding CPU bo during uploads
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Here's something else to test wrt scrolling:

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index ac3867e..fc3f889 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -5448,6 +5448,7 @@ sna_self_copy_boxes(DrawablePtr src, DrawablePtr dst, GCPtr gc,
                goto fallback;
        }
 
+       sna_pixmap_move_to_gpu(pixmap, MOVE_READ | MOVE_WRITE | MOVE_ASYNC_HINT);
        if (priv->gpu_damage || (priv->cpu_damage == NULL && priv->gpu_bo)) {
                assert(priv->gpu_bo);

And then please test

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index ac3867e..c9af183 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -5487,7 +5487,7 @@ fallback:
                if (!sna_pixmap_move_to_cpu(pixmap, MOVE_READ | MOVE_WRITE))
                        goto free_boxes;
 
-               if (alu == GXcopy && pixmap->drawable.bitsPerPixel >= 8) {
+               if (alu == GXcopy && pixmap->drawable.bitsPerPixel >= 8 && 0) {
                        assert(pixmap->devKind);
                        if (sigtrap_get() == 0) {
                                FbBits *dst_bits, *src_bits;

Tested with -intel at commit f19195f7ea317f5601543724c725c4b63fdc3f60, both corruptions happen with no complaint by --enable-debug=pixmap.

Will now update to latest -intel to include commit from comment #3

Are changes from comment #4 and comment #5 to test individually on top of the one from comment #3 or cumulative (3, 3+4, 3+4+5 or 3, 3+4, 3+5 or even 3, 4, 5)?

#4 and #5 should be applied on top of the current tree. They are mutually exclusive: #4 tests whether the bug is on the CPU or GPU side of things, and #5 tests the custom memmove branch vs fbBlt.

I think I nailed it,

commit e3a0e40310b6c46b2f887bc0d75b11cc06ec8fa0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 11 18:07:46 2014 +0100

    sna: Fix direction flags for memmove
    
    Under a compositor, the current deltas may invert the sense of the copy
    direction, causing scrolling corruption. Simplify handling those flags
    by making them invariant for the function.
    
    Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79843
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

That should fix the scrolling. The jury is still out as for the cause of the other type of corruption.

Created attachment 100899 [details]
Remaining corruption

(In reply to comment #8)
> That should fix the scrolling. The jury is still out as for the cause of the
> other type of corruption.

It looks like this effectively fixes the hexchat/message pane scrolling issue where whole area is filled with last line.

A similar corruption remains (happens more sporadically or less easy to reproduce, even in a row when it happens).
On screenshot:
- left is expected rendering
- middle is corruption when scrolling down to bottom with touchpad scroll area
- right is corruption when scrolling exactly one line down to bottom with scrollbar arrow
(black boxes is my work to hide part of mailbox name for privacy reasons)
Each time it happens it's that same spurious Trash folder showing up (no idea where it comes from and why it's so much indented to the right and with simple folder icon instead of trash icon).



Other corruption case still happens as you expected.

Maybe I accidentally fixed this? :)

Hi Bruno, could you please provide information to last comment
Thanks

No updates for a long time. Is this still an issue?

(In reply to Ileana from comment #12)
> No updates for a long time. Is this still an issue?

Sorry for not replying earlier.

For now I'm not seeing corruption of any kind (running linux 4.4.0,xf86-video-intel 2.99.917, libdrm 2.4.65) nor did I see corruptions in recent times. Though it's hard to tell if the issue is gone or if it has become much harder to trigger.

So closing as `works for me`.