Bug 45092

Created attachment 55975 [details]
X log

Created attachment 55976 [details]
dmesg

Created attachment 55977 [details]
Output of xrandr --verbose

Possibly related bug 28813. Or we may just have never got the swizzling correct for crestline?

Johnny, can you please download intel-gpu_tools from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ and run through a make test. However we may need to throw in a memory hog in order to exercise the swap paths.

Ok, a few things:
- Can you try to grab another screenshot, preferrably where the background image (or any other large image) shows some corruptions? Because gui elements are usually pretty small and have mostly uniform&flat coloring it's much harder to see the pattern.

- Please attach the output of intel_reg_dumper from the intel-gpu-tools (at last v1.1, prefarrably git). You need to install a bunch of dependencies for that to compile.

- As Chris mentioned, please run the i-g-t testsuite. If that one blows up, the relevant tests are tests/gem_tiled_*, you can run these manually.

Created attachment 56003 [details]
Damaged desktop

I have uploaded a shot of the desktop with damages.

As I already wrote, I can't build intel-gpu-tools because of an error. Here's the output of autogen.sh:

autoreconf-2.68: Entering directory `.'
autoreconf-2.68: configure.ac: not using Gettext
autoreconf-2.68: running: aclocal 
configure.ac:52: error: xorg-macros version 1.16 or higher is required but 1.15.0 found                                                                      
/usr/share/aclocal/xorg-macros.m4:39: XORG_MACROS_VERSION is expanded from...                                                                                
configure.ac:52: the top level                                                                                                                               
autom4te-2.68: /usr/bin/m4 failed with exit status: 1                                                                                                        
aclocal-1.11: /usr/bin/autom4te-2.68 failed with exit status: 1                                                                                              
autoreconf-2.68: aclocal failed with exit status: 1

I guess to succeed, I have to have a newer util-macros package for which I have to have a newer X server. I don't know whether I want to do that. Can't we get around without it?

> --- Comment #7 from Johnny Wezel <freedesktop-
> I guess to succeed, I have to have a newer util-macros package for which I have
> to have a newer X server. I don't know whether I want to do that. Can't we get
> around without it?

Nope, newer X server not required at all. Either you upgarde the dev
package (xutils-dev on debian) or you grab the single missing file
from source:

http://cgit.freedesktop.org/xorg/util/macros/

Run ./autogen.sh and copy xorg-macros.m4 into /usr/share/aclocal

That should make this work. Btw for quick questions like this it's
usually faster to ask for help on irc, #intel-gfx on the freenode
network.

Created attachment 56044 [details]
Output of intel_reg_dumper

OK, got it with intel_reg_dumper (had to update libdrm and check whether the bug is still there because of that [yes, it is])

Thanks a lot for the reg dump and the screenshot, perfect match with what Chris suspected. Can you please also grab the same registers as in https://bugs.freedesktop.org/show_bug.cgi?id=28813#c21

Sure:

0x10200 : 0xF0002
0x10204 : 0x0
0x100E0 : 0x0
0x11234 : 0x910C1800
0x11334 : 0x910C1800

Can you try to set bit20 in register 0x10204 like this?

intel_reg_write 0x10204 0x100000

Note though that it's unclear from the documentation what this bit exactly does, and it has the potential to corrupt system memory (and not just graphics stuff). So I highly advise you to try this on a throw-away disk/installation.

But it's the only thing I could find, so please try it if you can.

This is the output of the command:

Value before: 0x0
Value after: 0x0

There is no effect from the command. Problems persist.

I'm not sure whether this helps but another effect of swapped back memory is that in GTK+ programs, icons lose their images, like shown in the last screenshot.

Created attachment 56154 [details]
Damaged GTK+ icons

There is no way to make the icon's images to reappear.

Ok, so the hw doesn't allow this bit to be flipped after initialization. Which makes sense. I need to do more documentation reading and also some patch writing before I'll have something new for you to test.

For the damaged icons: Does this not happen when swap is disabled?

The icons look more like the ddx bug:

commit 2174f840158aa9cfa370ade38be28f8dc8e4b526
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 3 20:41:31 2011 +0000

    uxa: Remove caching of surface binding location
    
    If the pixmap were to be used multiple times within a batch with
    mulitple formats, the cache would only return the initial location with
    the incorrect format and so cause rendering glitches. For instance, GTK+
    uses the same pixmap as an xrgb source and as an argb mask in order to
    premultiply and composite in a single pass. Rather than introduce an
    overly complication caching (handle, format) mechanism, kiss and remove
    the invalid implementation.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40926
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

release in 2.16.902

The icons blacken only after swapping. IMHO this is not a GTK+ bug.

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

Got this again, under GNOME Shell, after using suspend to disk.  (I've a screenshot if you need more of them.)  Restarting GNOME Shell with Alt-F2 r fixed the corruption.

Is there anything I can to do help debug this?

(In reply to comment #20)
> Got this again, under GNOME Shell, after using suspend to disk.  (I've a
> screenshot if you need more of them.)  Restarting GNOME Shell with Alt-F2 r
> fixed the corruption.
> 
> Is there anything I can to do help debug this?

Unfortunately not. I have a machine which has this issue, too. And we have tests in i-g-t that can easily reproduce it. The problem is simply that I have no idea how to fix it (without rewriting the entire driver, that is).

What's the grand plan? Everyone needs to be aware of physical page locations and swizzling again?

One thing you could try is to grab the latest verion of intel-gpu-tools from git and run the testsuite with make test. That should give you a nice set of failing tests with "tiled" in their names.

Then try to decrease the amount of memory linux uses with the mem=xxxm boot parameter, until all these tests with 'tiled' work reliably. The best result would be to figure out that things work for mem=xxxm, but not for mem=xxx+1m.

Created attachment 81971 [details] [review]
Hack to prevent movement of swizzled pages

A hack for you to please test.

Timeout. What is the status of the bug?

Johnny, still an issue? Did you try the proposed hack patch?

Hi i had the same problem in debian Wheezy and i managed to solve changing my hibernation method to TuxOnIce.

I hope this extra info could help solve the problem.

Excuse me, what are the workarounds for the problem besides patching the drm kernel module? is it possible to invalidate pixmap cache that GTK uses?

2nd: the bug is in "NEEDINFO" state. What kind of info is needed?

Disabling swap, replace with more ram.

And by the time, please retest with latest drm-intel-nightly

(In reply to Rodrigo Vivi from comment #29)
> And by the time, please retest with latest drm-intel-nightly

Known hardware issue that remains unresolved. The patch we want tested is attached to this bug.

Ok I've finally gotten around to polish Chris' patch and update testcase:

http://patchwork.freedesktop.org/patch/37073/

As soon as I have a few  tested-by reports I'll pull this in, so please go wild. Patch applies on top of latest drm-intel-nightly.

Workaround is now merged into drm-intel-nightly, should land in 3.19

commit 14a369b6c9bdb40cebdac5a248321a05119fe02b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Nov 20 09:26:30 2014 +0100

    drm/i915: Pin tiled objects for L-shaped configs

Note that this is v2, v1 was a bit WARNING-happy.

(In reply to Daniel Vetter from comment #32)
> Workaround is now merged into drm-intel-nightly, should land in 3.19
> 
> commit 14a369b6c9bdb40cebdac5a248321a05119fe02b
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Nov 20 09:26:30 2014 +0100
> 
>     drm/i915: Pin tiled objects for L-shaped configs
> 
> Note that this is v2, v1 was a bit WARNING-happy.

Assuming the problem was fixed by the patch above, since it has been almost a month. Please reopen if necessary.

I have this chip, running with version 2:2.99.916+git201412 of the Intel driver from xorg-edgers didn't help. I used the DebugWait trick from bug 37326 and it seemed to help.

Created attachment 111328 [details]
Corrupted desktop

I have 3145990144 bytes of RAM and I think it may also be bug 55000. But since that bug does not mention the DebugWait workaround, and it works for me, I don't know what to think.

I was wrong, DebugWait didn't help. I disabled DebugWait again of course.

It looks as if upgrading to kernel v3.19-rc1 did though.

I got the kernel here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc1-vivid/

However, the commit ID of the patch doesn't match the one Daniel Vetter gave above. I found this though, with the same commit description: https://github.com/torvalds/linux/commit/656bfa3afc14e45e2d9e1624bf60d79b3beb12f2

In debugfs, I can see that the new code paths are getting hit:

# cat /sys/kernel/debug/dri/0/i915_swizzle_info
bit6 swizzle for X-tiling = bit9/bit10/bit11
bit6 swizzle for Y-tiling = bit9/bit11
DDC = 0x000f0002
DDC2 = 0x00000000
C0DRB3 = 0x0000
C1DRB3 = 0x0000
L-shaped memory detected