Created attachment 81774 [details] output System Environment: -------------------------- Arch: x86_64 Platform: Ironlake/sandybridge/ivybridge/haswell Libdrm: (master)libdrm-2.4.45-13-g378bb47a784a3808c9b256fe7a52e10a4fcabf92 Mesa: (master)adf8afa168fe9fe2e4a2b35afc3003040d05273f Xserver: (master)xorg-server-1.14.99.1-130-g77e51d5bbb97eb5c9d9dbff9a7c44d7e53620e68 Xf86_video_intel:(master)2.21.10-67-g3a787da7e888da7e9943be94bd1cb177fe1495ab Cairo: (master)7b8fc77bb974fbd4fbc697405a8b6aec748bb7f2 Libva: (staging)e9e685fe752b9865ba9e28cb63e18ce3f8aed2a0 Libva_intel_driver:(staging)bb24c8a81e512d19aad0359d81f7247e6f20cc29 Kernel: (drm-intel-nightly) 03d25b4548499254d66f1ee0bae8b796097a41ed Bug detailed description: ------------------------- It fails on Ironlake/sandybridge/ivybridge/haswell if enable SNA, It works well with UXA. Bisect shows:9026bb954646c0425360c2236e26c79d097142cd is the first bad commit. commit 9026bb954646c0425360c2236e26c79d097142cd Author: Chris Wilson <chris@chris-wilson.co.uk> AuthorDate: Fri Jun 28 15:59:17 2013 +0100 Commit: Chris Wilson <chris@chris-wilson.co.uk> CommitDate: Sat Jun 29 16:08:30 2013 +0100 sna: Inspect the dirty boxes when querying whether damage contains a rectang This helps in the cases where we have subtracted a small number of rectangles from an all-damage pixmap (such as a number of successive GetImage, PutImage operations). The danger is that we end up searching a long list of dirty boxes - maybe just search the first chunk if that becomes noticeable? Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reproduce steps: ---------------- 1. xinit 2. ./rendercheck -o src,over,overreverse,xor -t blend
That bisect looks is a red herring. As this test worksforme (with the expected rounding errors) time for you to do a little more digging into what's broken on your machines.
Can you attach an Xorg.0.log from a failing machine so that I can confirm a few details?
Created attachment 81789 [details] Xorg.0.log
3.10.0-rc5_20130627_irq_review_520dc+ doesn't look like -nightly. Can you please try with -nightly, most importantly with commit 22fd5ca947b58901927d100d2b1aa0f1672b3435 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 28 16:54:08 2013 +0100 drm/i915: Only clear write-domains after a successful wait-seqno
Created attachment 81790 [details] Xorg.0.log
So I have been able to reproduce this on gen2, gen3, and gen4, but not any of my gen5+ boxes. I've poked all the internal damage tracking to no avail, it is all self-consistent at least. Interesting adding the debugging (thus slowing it down) makes a few of the failures disappear - so it would appear to be a timing / caching issue.
Nasty, nasty heisenbug. The more debugging you enable, the harder it was to see. In the end, the bisect was spot and I was remiss for asuming it was just going to be another example of the kernel bug. commit ad0afda3fe4f5e408e3610d8b76fdc7d1af33138 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jul 1 22:26:29 2013 +0100 sna: Fix checking the dirty boxes I forgot how insane the data structure for the list of dirty boxes attached to the damage is. It is neither a simple list, nor does not store the count of boxes within each chunk. Fixes regression from commit 9026bb954646c0425360c2236e26c79d097142cd [2.21.11] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 28 15:59:17 2013 +0100 sna: Inspect the dirty boxes when querying whether damage contains a rectangle A side effect is that we now make sure that there is an upper bound to the amount of searching we do for the no-reduce fast path. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66430 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Verified.Fixed by commit ad0afda3fe4f5e408e3610d8b76fdc7d1af33138.
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.