Ok, any chance of seeing this under debug=full?

Created attachment 64280 [details]
Xorg.log (packed, 5M)

(In reply to comment #1)
> Ok, any chance of seeing this under debug=full?

X won't start with debug=full:
#3  0x00007ff428d27cd2 in __GI___assert_fail (assertion=0x7ff4250dc43d "0", file=0x7ff4250dc55e "sna_accel.c", line=226, 
    function=0x7ff4250e1b60 <__PRETTY_FUNCTION__.21382> "_assert_pixmap_contains_box") at assert.c:103
#4  0x00007ff424ffa4f1 in _assert_pixmap_contains_box (pixmap=0x288baa0, box=0x7fff3d605530, function=0x7ff4250e144e <__FUNCTION__.22152> "sna_copy_boxes")
    at sna_accel.c:226
#5  0x00007ff425005c08 in sna_copy_boxes (src=0x2899030, dst=0x2808720, gc=0x2808f40, region=0x7fff3d605530, dx=0, dy=-1052, bitplane=0, closure=0x0)
    at sna_accel.c:3923
#6  0x00007ff425007c1c in sna_do_copy (src=0x2899030, dst=0x2808720, gc=0x2808f40, sx=0, sy=0, width=1920, height=28, dx=0, dy=1052, 
    copy=0x7ff425005ae8 <sna_copy_boxes>, bitPlane=0, closure=0x0) at sna_accel.c:4462
#7  0x00007ff42500829f in sna_copy_area (src=0x2899030, dst=0x2808720, gc=0x2808f40, src_x=0, src_y=0, width=1920, height=28, dst_x=0, dst_y=0)
    at sna_accel.c:4566
#8  0x00000000004f97dd in damageCopyArea (pSrc=0x2899030, pDst=0x2808720, pGC=0x2808f40, srcx=0, srcy=<optimized out>, width=1920, height=28, dstx=0, dsty=0)
    at damage.c:824
#9  0x000000000043493b in ProcCopyArea (client=0x27be820) at dispatch.c:1623
#10 0x00000000004388a1 in Dispatch () at dispatch.c:428
#11 0x0000000000427965 in main (argc=7, argv=0x7fff3d6058d8, envp=<optimized out>) at main.c:288

Haven't had that in a long time... I wonder what I broke, thanks!

Oops, I moved the validation step too early:

commit 818c21165c746b7b410a6e6e23b1675d88db685d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 16 16:28:00 2012 +0100

    sna: Fixup pixmap validation for sna_copy_area()
    
    Remember to offset the box by the drawable deltas in order to
    compensate for compositing.
    
    Reported-by: Jiri Slaby <jirislaby@gmail.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=52142
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Can you try again? Many, many thanks.

(In reply to comment #4)
> Can you try again? Many, many thanks.

Yea, the log is 800M raw (25M packed):
http://www.fi.muni.cz/~xslaby/sklad/Xorg.0.log.xz

It happened end_of_the_log minus approx. 15 sec.

There is a major oddity with the xterm pixmap -- it ends up wholly damaged on the CPU and not migrating back to the GPU. That's one bug...

That issue should be improved by

commit 1f79e877fb6602bd0f9dd14ac9c3511f3b7044fb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 16 21:18:24 2012 +0100

    sna: Share the pixmap migration decision with the BLT composite routines

I was puzzled by the glyph DBG then realised I was printing only half the information required.

I would very much appreciate a new debug=full log to compare with, thanks.

Is your g33 a 64-bit build? If so,

commit bee1a14618797b3d3a1c1a20eb72644fa907c048
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 18 09:38:32 2012 +0100

    sna: Fix processing of the last fallback box
    
    The evil typo caused us to misalign the clip boxes and run over a
    garbage array on 64-bit builds.

will definitely help.

Judging by your Xorg.log, I'm going with bee1a146 as the fix.

(In reply to comment #8)
> Is your g33 a 64-bit build? If so,
> 
> commit bee1a14618797b3d3a1c1a20eb72644fa907c048
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Jul 18 09:38:32 2012 +0100
> 
>     sna: Fix processing of the last fallback box
> 
>     The evil typo caused us to misalign the clip boxes and run over a
>     garbage array on 64-bit builds.
> 
> will definitely help.

No, it did not entirely :(. I'm at 2.20.1-9-gde707b7, but it is still there in some sense.
kaffeine --help gives:
  --help                    Zobrazit nápovědu k přepínačům
  --help-qt                 Zobrazit Qt konkrétních přepínačů
  --help                    Zobrazit nápovědu k přepínačům
  --help-qt                 Zobrazit Qt konkrétních přepínačů
  --help                    Zobrazit nápovědu k přepínačům
  --help-qt                 Zobrazit Qt konkrétních přepínačů
  --help-kde                Zobrazit KDE konkrétních přepínačů
  --help-kde-tempfile       Zobrazit Dočasný soubor KDE konkrétních přepínačů
  --help-all                Zobrazit všechny přepínače
  --author                  Zobrazit informaci o autorech
  -v, --version             Zobrazit informaci o verzi
  --license                 Zobrazit informaci o licenci
  --                        Konec přepínačů
etc.

I.e. only two lines are repeated, then there is a meaningful output.

Ok, I'm seeing something very similar if I mix flashplayer and an xterm. After some time I see a stutter and then damage tracking is very confused. Hmm. I've seen one recent bug in IGNORE_CPU, but I'm expecting a cluster.

I think this instance of the bug will be related to:

commit e6cb5d93eaa01e7f4763f797bba341f3cc481d98
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 30 11:14:58 2012 +0100

    sna: Avoid overlapping gpu/cpu damage with IGNORE_CPU
    
    We cannot simply ignore the presence of CPU damage with IGNORE_CPU but
    must remember to discard it.


Waiting to see if I can find anything else.

I believe I have this fixed, or at least the failures locally:

commit 46ec9b0ed55d0fcade40f92206e59c02e402d870
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 31 17:41:34 2012 +0100

    sna: Update DPMS mode on CRTC after forcing the outputs on
    
    If we forcibly update the outputs to be on, then the core will not issue
    its on DPMS event and we miss out on updating the CRTC bookkeeping in
    sna_crtc_dpms(). So we need to update the flag on the CRTC as we
    manipulate the outputs during modesetting.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=52142
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

commit 8f166d26b8a93592939068c5a8d160981c724cfd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 31 11:58:24 2012 +0100

    sna: Be more careful with damage reduction during CompositeRectangles
    
    We actually need to force DAMAGE_ALL in case we are promoting the GPU
    pixmap.

As always please let me know of any and all issues you encounter, many thanks.