Bug 26766

The commit on drm-intel-next was rebased recently, so the commit number changed. We find this was caused by the commit 10ae9bd25acf394c8fa2f9d795dfa9cec4d19ed6. 
commit 10ae9bd25acf394c8fa2f9d795dfa9cec4d19ed6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Feb 1 13:59:17 2010 +0100

    drm/i915: blow away userspace mappings before fence change

    This aligns it with the other user of i915_gem_clear_fence_reg,
    which blows away the mapping before changing the fence reg.

    Only affects userspace if it races against itself when changing
    tiling parameters, i.e. behaviour is undefined, anyway.

    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Eric Anholt <eric@anholt.net>

I've re-reviewed the changes in my patch. Only change is that the set_tiling ioctl drops userspace mappings before. Later patches also reuse the put_fence function change with in the fence stealing code. In other words: I don't see how this possibly could affect _anything_.

We can't check whether this patch is the problem by reverting it - this will break the new fence stealing code. I'll see into prepping a patch that does undo just these changes to set_tiling, just to be sure.

Created attachment 33877 [details]
revert of bad commit against 2.6.34-rc1

Please apply this patch to test whether the changes in my patch really cause the problem. Only compile-tested, so might blow up ;)

(In reply to comment #3)
> Created an attachment (id=33877) [details]
> revert of bad commit against 2.6.34-rc1
> Please apply this patch to test whether the changes in my patch really cause
> the problem. Only compile-tested, so might blow up ;)

I patched you attachment on drm-intel-next branch, it works well. And if I only revert commit 10ae9bd25acf394c8fa2f9d795dfa9cec4d19ed6 on drm-intel-next branch, it also works well. 

Created attachment 33949 [details]
set_tiling hack

Ok, I've got a few theories as to what might blow up. Can you please test this patch against drm-intel-next (without any reverts) to see whether this solves the problem. Just to check that I'm not walking down the wrong road. I simply don't have the hw to test this myself.

Also please upload your dmesg after running the failing tests.

(In reply to comment #5)
> Created an attachment (id=33949) [details]
> set_tiling hack
> Ok, I've got a few theories as to what might blow up. Can you please test this
> patch against drm-intel-next (without any reverts) to see whether this solves
> the problem. Just to check that I'm not walking down the wrong road. I simply
> don't have the hw to test this myself.
> Also please upload your dmesg after running the failing tests.

With this patch, tex3d still fails with the output as following. And its xorg.log and dmesg are in attachment. Kernel is buillt upon the 338d762fc2dc2c1493813123fc4cea998bb3e683 on drm-intel-next branch. 
[root@x-g45c piglit]# ./bin/tex3d -auto
Render 3D texture: Mismatch at 0x1x0
 Expected: 75,93,69,126
 Readback: 64,0,0,65
Failure with texture size 2x16x16, format = GL_RGBA
PIGLIT: {'result': 'fail' }

Created attachment 33981 [details]
dmesg of running tex3d

Created attachment 33982 [details]
xorg.0.log after running tex3d

Can you please check whether the patch from bug #26993 does fix the problem?

(In reply to comment #9)
> Can you please check whether the patch from bug #26993 does fix the problem?

Yes,with that patch it works well.

*** This bug has been marked as a duplicate of bug 26993 ***

these 2 cases pass since April 7th.

Closing old verified.