Created attachment 33580 [details] xorg.0.log System Environment: -------------------------- Libdrm: (master)3130f94c6ee32668cb9f0b96b6c8e308a7bb3b11 Mesa: (master)cc7904ffa56b3f27de80bf31084dead12fb09ae0 Xserver: (master)780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Xf86_video_intel: (master)c2c670ef18755cf5c878edf8a6b7d1617f54fe73 Kernel: (drm-intel-next)9df30794f609d9412f14cfd0eb7b45dd64d0b14e Bug detailed description: ------------------------- Two piglit cases(texturing/tex3d, texturing/texredefine) regressed caused by kernel on drm-intel-next branch. On drm-intel-next branch, commit af86d4b0f064413d2f353a41cdc23b7dbff0823d works well, commit 9df30794f609d9412f14cfd0eb7b45dd64d0b14e fails. I will continue to bisect it. Reproduce steps: -------------------- 1. xinit 2. texturing/tex3d -auto
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.