backport BDW/CHV sna BLT fix
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xf86-video-intel |
Fix Released
|
Critical
|
|||
xserver-xorg-video-intel (Ubuntu) |
Fix Released
|
Undecided
|
Timo Aaltonen | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Utopic |
Fix Released
|
Undecided
|
Unassigned | ||
Vivid |
Fix Released
|
Undecided
|
Timo Aaltonen |
Bug Description
[Impact]
xserver crash on intel gen8 gfx with a test case
[Test case]
run 'rendercheck -o src,over,
[Regression potential]
slim, limited to gen8
[Other info]
needs three commits from upstream git
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #2 |
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #3 |
Please bisect the kernel and file another bug for X crashing and include the Xorg.0.log and gdb stacktrace (bt full).
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #4 |
5cc9ed4b9a7ac57
commit 5cc9ed4b9a7ac57
Author: Chris Wilson <email address hidden>
Date: Fri May 16 14:22:37 2014 +0100
Commit: Daniel Vetter <email address hidden>
CommitDate: Fri May 16 19:31:29 2014 +0200
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the m...
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #5 |
Created attachment 99571
Xorg.0.log
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #6 |
gdb --pid=`pidof Xorg` required.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #7 |
Also please update i-g-t to
commit 9911f3f0cf20244
Author: Chris Wilson <email address hidden>
Date: Thu May 22 10:20:33 2014 +0100
igt/
When the patch was merged, the ioctl numbers had to be adjusted to leave
no holes. Also there was a final piece of munging of the API to
downgrade unsynced userptr for export over dma-buf.
Signed-off-by: Chris Wilson <email address hidden>
and run igt/gem_
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #8 |
(In reply to comment #5)
> Also please update i-g-t to
>
> commit 9911f3f0cf20244
> Author: Chris Wilson <email address hidden>
> Date: Thu May 22 10:20:33 2014 +0100
>
> igt/gem_
>
> When the patch was merged, the ioctl numbers had to be adjusted to leave
> no holes. Also there was a final piece of munging of the API to
> downgrade unsynced userptr for export over dma-buf.
>
> Signed-off-by: Chris Wilson <email address hidden>
>
> and run igt/gem_
Run this case, system will lose network connection(BTW, this case takes more than 30 minutes). Then run reboot, system is no response.
output:
IGT-Version: 1.6-gff3c122 (x86_64) (Linux: 3.15.0-
Aperture size is 4096 MiB
Total RAM is 3852 MiB
Subtest input-checking: SUCCESS
Subtest usage-restrictions: SUCCESS
Subtest invalid-mapping: SUCCESS
Subtest forbidden-
Testing unsynchronized mappings...
Subtest create-
Subtest unsync-overlap: SUCCESS
Subtest unsync-unmap: SUCCESS
Subtest unsync-
Subtest unsync-
Using 2x2730 1MiB buffers
Verifying initialisation...
Cyclic blits cpu->gpu, forward...
Cyclic blits gpu->cpu, backward...
Random blits...
Subtest coherency-unsync: SUCCESS
Subtest dmabuf-unsync: SUCCESS
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #9 |
Created attachment 99603
dmesg(gem_
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #10 |
(gdb) bt
#0 0x00007fda77ae0f77 in __GI_raise (sig=sig@entry=6) at ../nptl/
#1 0x00007fda77ae45e8 in __GI_abort () at abort.c:90
#2 0x00007fda77b1e4fb in __libc_message (do_abort=
at ../sysdeps/
#3 0x00007fda77b2a996 in malloc_printerr (ptr=0x2527c30, str=0x7fda77c32370 "double free or corruption (out)", action=3) at malloc.c:4923
#4 _int_free (av=<optimized out>, p=0x2527c20, have_lock=0) at malloc.c:3779
#5 0x0000000000436cfc in DoGetImage (planemask=
at dispatch.c:2170
#6 ProcGetImage (client=0x252b490) at dispatch.c:2181
#7 0x0000000000439bde in Dispatch () at dispatch.c:432
#8 0x000000000043db0a in dix_main (argc=2, argv=<optimized out>, envp=<optimized out>) at main.c:296
#9 0x00007fda77acbde5 in __libc_start_main (main=0x428250 <main>, argc=2, ubp_av=
stack_
#10 0x0000000000428281 in _start ()
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #11 |
Any other platforms affected?
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #12 |
(In reply to comment #9)
> Any other platforms affected?
Only happens on BDW.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #13 |
It works well with UXA.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #14 |
(In reply to comment #11)
> It works well with UXA.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #15 |
(In reply to comment #11)
> It works well with UXA.
How? UXA doesn't even use this code.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #16 |
Please recompile the ddx with --enable-debug.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #17 |
Also note that a bisect result that points to the enabling of a feature is not exhaustative. If you compile the ddx with --enable-userptr you can regression check the ddx over the last couple of years. If you reorder the kernel commits, you can regression check the kernel over the introduction of bdw support. Without taking those steps, it is misleading to point to the feature commit as the *root cause* of the regression.
In freedesktop.org Bugzilla #79053, Daniel-ffwll (daniel-ffwll) wrote : | #18 |
Re-adding regression tag since it's an overall degradation, so need to track it as such.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #19 |
(In reply to comment #14)
> Please recompile the ddx with --enable-debug.
add --enable-debug
(gdb) bt
#0 0x00007f3d325b2f77 in __GI_raise (sig=sig@entry=6)
at ../nptl/
#1 0x00007f3d325b65e8 in __GI_abort () at abort.c:90
#2 0x00007f3d325f04fb in __libc_message (do_abort=
fmt=
at ../sysdeps/
#3 0x00007f3d325fc996 in malloc_printerr (ptr=0xf31570,
str=
at malloc.c:4923
#4 _int_free (av=<optimized out>, p=0xf31560, have_lock=0) at malloc.c:3779
#5 0x0000000000434632 in DoGetImage (planemask=
width=5, y=0, x=0, drawable=<optimized out>, format=<optimized out>,
client=
#6 ProcGetImage (client=<optimized out>) at dispatch.c:2181
#7 0x0000000000437427 in Dispatch () at dispatch.c:432
#8 0x000000000043b20a in dix_main (argc=2, argv=0x7fffeaab
envp=<optimized out>) at main.c:296
#9 0x00007f3d3259dde5 in __libc_start_main (main=0x4268f0 <main>, argc=2,
ubp_
rtld_
#10 0x0000000000426921 in _start ()
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #20 |
Hmm, so it passes the sanity checks. Next up:
Please test with
diff --git a/src/sna/
index f104a69..32f579a 100644
--- a/src/sna/
+++ b/src/sna/
@@ -73,7 +73,7 @@
#define USE_ZERO_SPANS 1 /* -1 force CPU, 1 force GPU */
#define USE_CPU_BO 1
#define USE_USERPTR_UPLOADS 1
-#define USE_USERPTR_
+#define USE_USERPTR_
#define USE_COW 1
#define UNDO 1
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #21 |
(In reply to comment #18)
> Hmm, so it passes the sanity checks. Next up:
>
> Please test with
>
> diff --git a/src/sna/
> index f104a69..32f579a 100644
> --- a/src/sna/
> +++ b/src/sna/
> @@ -73,7 +73,7 @@
> #define USE_ZERO_SPANS 1 /* -1 force CPU, 1 force GPU */
> #define USE_CPU_BO 1
> #define USE_USERPTR_UPLOADS 1
> -#define USE_USERPTR_
> +#define USE_USERPTR_
> #define USE_COW 1
> #define UNDO 1
Works well with this patch.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #22 |
Ok, it looks like bdw is just rendering outside of its target. It could just be a bug with the render setup, or the hardware might genuinely foul bytes within the page surrounding the object.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #23 |
This should force that operation to use the BLT rather than the render pipeline, please test.
diff --git a/src/sna/
index a307d9e..7e6f9c8 100644
--- a/src/sna/
+++ b/src/sna/
@@ -16272,6 +16272,10 @@ sna_get_
+ kgem_set_
+ kgem_bo_
+ kgem_bo_
+
ok = sna->render.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #24 |
Created attachment 100509
Check offset alignment before RENDER with a userptr
If my hunch is correct, this should be the right fix.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #25 |
Which is consistent with BDW being the first to fail, since that has more severe alignment restrictions than gen7 and earlier.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #26 |
(In reply to comment #22)
> Created attachment 100509 [details] [review]
> Check offset alignment before RENDER with a userptr
>
> If my hunch is correct, this should be the right fix.
Test this patch, It still exists.
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 25...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #27 |
Created attachment 100511
Check offset alignment before RENDER with a userptr
A more complete version of that patch, worth testing as well.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #28 |
(In reply to comment #25)
> Created attachment 100511 [details] [review]
> Check offset alignment before RENDER with a userptr
>
> A more complete version of that patch, worth testing as well.
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (4, 1) --
R ...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #29 |
Did you test with comment 21?
How about if you use the following xorg.conf snippet?
Section "Device"
Identifier "Intel"
Driver "intel"
Option "AccelMethod" "blt"
EndSection
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #30 |
(In reply to comment #27)
> Did you test with comment 21?
>
> How about if you use the following xorg.conf snippet?
>
> Section "Device"
> Identifier "Intel"
> Driver "intel"
> Option "AccelMethod" "blt"
> EndSection
It still has this issue.
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.00...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #31 |
Whilst I think this is related to the userptr blit, there is a chance that the corruption is due to a render operation whilst the userptr is still bound in the aperture. So can I ask you retest with the latest stack?
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #32 |
(In reply to comment #29)
> Whilst I think this is related to the userptr blit, there is a chance that
> the corruption is due to a render operation whilst the userptr is still
> bound in the aperture. So can I ask you retest with the latest stack?
Test on latest -nightly kernel and X.It still exists.
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 4) --
R G B A
got: 0.00...
In freedesktop.org Bugzilla #79053, Paul-a-parenteau (paul-a-parenteau) wrote : | #33 |
Chris, based on this latest testing result, do you have any more ideas on this bug?
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #34 |
(In reply to comment #31)
> Chris, based on this latest testing result, do you have any more ideas on
> this bug?
It's a stray write from the render ring (I believe) that clobbers the blt used to transfer the results back. But no, I don't have enough to pin down where or why?
In freedesktop.org Bugzilla #79053, Paul-a-parenteau (paul-a-parenteau) wrote : | #35 |
Is it possible to use an ITP, setting a watchpoint on the memory location that is being written to, so you can grab the IP and trace it back to the offending function? Or, is it more like the HW is being programmed incorrectly and therefore scribbles past where it should? Damien has an ITP if needed.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #36 |
(In reply to comment #33)
> Or, is it more like the HW is being programmed
> incorrectly and therefore scribbles past where it should?
I did a run on fulsim/bdw yesterday now that the internal tree has userptr as well. It does not suffer the same stray writes, or issue any new complaints. But we have already experienced that the hardware behaves differently to the simulator...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #37 |
Meh, I can do
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index dfaf878..6a9543d 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -1063,6 +1063,9 @@ static bool test_has_
if (kgem->gen == 040)
+ if (kgem->gem >= 0100)
+ return false; /* FIXME */
+
if (posix_
to hide the issue until fixed. In fact, done. Please let me know if they are another issues that show up on bdw that may help explain this.
commit 3f4da671b0a570d
Author: Chris Wilson <email address hidden>
Date: Wed Jun 25 08:01:57 2014 +0100
sna: Disable userptr for bdw
Something fishy is afoot. But let's kill this particularly worrisome
regression so that we can do a full round of testing.
References: https:/
Signed-off-by: Chris Wilson <email address hidden>
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #38 |
Test on commit ea6b0bb8e1b358d
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #39 |
Fixed.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #40 |
It's not fixed yet - just the immediate crash masked.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #41 |
Jani, the bug is low priority as it no longer affects the next release.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #42 |
And the [regression] if that makes you feel happier.
In freedesktop.org Bugzilla #79053, Jani-nikula (jani-nikula) wrote : | #43 |
(In reply to comment #40)
> And the [regression] if that makes you feel happier.
I'm indifferent, but my script is a stubborn little bugger.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #44 |
I can't make progress on this bug without access to bdw.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #45 |
Mika tried with userptr re-enabled and with using userptr for the dcoords readback and found it worked...
So let's re-enable userptr and cross our fingers.
commit 9e397830f5ea56f
Author: Chris Wilson <email address hidden>
Date: Thu Sep 11 17:02:37 2014 +0100
sna/gen8: Re-enable userptr
Current testing says that it is stable now... Let's see how long that
holds.
References: https:/
Cc: Mika Kuoppala <email address hidden>
Signed-off-by: Chris Wilson <email address hidden>
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #46 |
Test on commit 9e397830f5ea56f
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (3, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (4, 1) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test err...
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #47 |
Hmm, the code path that originally failed is still disabled. Could you send me a log file of the crash with xf86-video-intel compiled with --enable-
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #48 |
Mika, mind if I add this to the list of things for you to investigate? It should be a nice change of pace...
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #49 |
add --enable-
make[4]: Leaving directory `/GFX/build/
make[4]: Entering directory `/GFX/build/
CC blt.lo
CC kgem.lo
CC sna_accel.lo
sna_accel.c: In function 'sna_poly_
sna_accel.c:8920:7: warning: variable 'degenerate' set but not used [-Wunused-
bool degenerate = true;
^
CC sna_acpi.lo
CC sna_blt.lo
CC sna_composite.lo
CC sna_cpu.lo
CC sna_damage.lo
CC sna_display.lo
In file included from sna.h:112:0,
sna_display.c: In function 'sna_output_
sna_display.
DBG(("%s(%s)\n", __FUNCTION__, output->name));
fb/fb.h:43:21: note: in definition of macro 'DBG'
#define DBG(x) LogF x
sna_display.
DBG(("%s(%s)\n", __FUNCTION__, output->name));
fb/fb.h:43:21: note: in definition of macro 'DBG'
#define DBG(x) LogF x
sna_display.c: In function 'sna_output_
sna_display.
DBG(("%s(%s)\n", __FUNCTION__, output->name));
fb/fb.h:43:21: note: in definition of macro 'DBG'
#define DBG(x) LogF x
sna_display.
xf86OutputPtr output = sna_output->base;
^
make[4]: *** [sna_display.lo] Error 1
make[4]: Leaving directory `/GFX/build/
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/GFX/build/
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/GFX/build/
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/GFX/build/
make: *** [all] Error 2
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #50 |
(In reply to comment #47)
> add --enable-
commit e3edf2948467ad9
Author: Chris Wilson <email address hidden>
Date: Fri Sep 12 07:53:12 2014 +0100
sna: DBG compile fix
Dereference the right output for the name in the new backlight
functions.
Signed-off-by: Chris Wilson <email address hidden>
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #51 |
Created attachment 106166
Xorg.0.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #52 |
(In reply to comment #49)
> Created attachment 106166 [details]
> Xorg.0.
That's odd, the log just stops. Was there anything on the terminal or in the gdm (or equiv) logs?
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #53 |
[ 2856.227] (II) intel(0): SNA initialized with generic backend
Hmm, that's broken.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #54 |
[ 2856.225] (**) intel(0): Option "AccelMethod" "blt"
is why.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #55 |
Hmm, that log makes the failure path look even simpler: a single BLT copy in the batch to write into the userptr. It would be the same code path on every generation (certainly if Option "AccelMethod" "BLT" is used).
Something you can do for a quick check:
ickle@nuc-
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 66adae8..b1cf92a 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -2581,7 +2581,7 @@ bool __kgem_
return true;
}
-#if 0
+#if 1
static void kgem_commit_
{
struct kgem_request *rq = kgem->next_request;
which enables the sanity check on the kernel relocation values.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #56 |
(In reply to comment #53)
> Hmm, that log makes the failure path look even simpler: a single BLT copy in
> the batch to write into the userptr. It would be the same code path on every
> generation (certainly if Option "AccelMethod" "BLT" is used).
>
> Something you can do for a quick check:
>
> ickle@nuc-
> diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> index 66adae8..b1cf92a 100644
> --- a/src/sna/kgem.c
> +++ b/src/sna/kgem.c
> @@ -2581,7 +2581,7 @@ bool __kgem_
> return true;
> }
>
> -#if 0
> +#if 1
> static void kgem_commit_
> {
> struct kgem_request *rq = kgem->next_request;
>
>
> which enables the sanity check on the kernel relocation values.
Test this patch, It still fail.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 550 requests (550 known processed) with 0 events remaining.
xinit: connection to X server lost
xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0"
[1]+ Done xinit (wd: /GFX/build/
(wd now: /GFX/Test/
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #57 |
The idea was that is might change how it failed to reveal more information... Hence a fresh debug log is required with the patch (sorry for not being clear).
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #58 |
Created attachment 106169
Xorg.0.log(patch)
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #59 |
Thanks. One last little debugging technique to try. Please apply
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 66adae8..6e679b0 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -92,7 +92,7 @@ search_
#endif
#define SHOW_BATCH_BEFORE 0
-#define SHOW_BATCH_AFTER 0
+#define SHOW_BATCH_AFTER 1
#if 0
#define ASSERT_IDLE(kgem__, handle__) assert(
and attach the resulting logfile.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #60 |
Created attachment 106170
Xorg.0.log(patch2)
(In reply to comment #57)
> Thanks. One last little debugging technique to try. Please apply
>
>
> diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> index 66adae8..6e679b0 100644
> --- a/src/sna/kgem.c
> +++ b/src/sna/kgem.c
> @@ -92,7 +92,7 @@ search_
> num_pages, unsigned flags);
> #endif
>
> #define SHOW_BATCH_BEFORE 0
> -#define SHOW_BATCH_AFTER 0
> +#define SHOW_BATCH_AFTER 1
>
> #if 0
> #define ASSERT_IDLE(kgem__, handle__) assert(
>
> and attach the resulting logfile.
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (3, 2) --
R G B A
got: ...
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #61 |
It also happens on BSW.
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #62 |
triangles sporadically has this issue on BSW. Fail rate: 3/5.
In freedesktop.org Bugzilla #79053, Mika-kuoppala (mika-kuoppala) wrote : | #63 |
Created attachment 107830
sna/kgem: Gen8 needs blt destination aligned with 32
In freedesktop.org Bugzilla #79053, Huax-lu (huax-lu) wrote : | #64 |
(In reply to Mika Kuoppala from comment #61)
> Created attachment 107830 [details] [review]
> sna/kgem: Gen8 needs blt destination aligned with 32
Fixed by this patch.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #65 |
(In reply to Mika Kuoppala from comment #61)
> Created attachment 107830 [details] [review]
> sna/kgem: Gen8 needs blt destination aligned with 32
Still feel slightly dubious about this - I think I need a more general check. But I'll wait on an investigative igt to see what the bad pattern is. If we can just get away with checking the origin alignment, it seems a simple enough w/a.
In freedesktop.org Bugzilla #79053, Daniel-ffwll (daniel-ffwll) wrote : | #66 |
Gavin just asked about this, apparently it blocks qa testing a bit as a high-prio item. So can we pull in the patch as a duct-tape while we try to figure out with igts what might be really wrong.
In freedesktop.org Bugzilla #79053, Daniel-ffwll (daniel-ffwll) wrote : | #67 |
Mika: We might also want to file an HSD about this if it's confirmed with a more minimal test.
In freedesktop.org Bugzilla #79053, Gavin Hindman (ghindman) wrote : | #68 |
Did this patch get merged?
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #69 |
(In reply to Gavin Hindman from comment #66)
> Did this patch get merged?
No, because it is not clear that it is the right solution. And the danger is if we do merge it we then ignore the hw issue...
In freedesktop.org Bugzilla #79053, Mika-kuoppala (mika-kuoppala) wrote : | #70 |
Created attachment 109634
[PATCH] sna/kgem: Gen8 blt broken when dest base offset has bit 4 set
Updated patch with more strict restriction to dest offset
In freedesktop.org Bugzilla #79053, Mika-kuoppala (mika-kuoppala) wrote : | #71 |
The current igt to explore this bug is at:
http://
Please test rendercoords with the new patch attached.
In freedesktop.org Bugzilla #79053, Li-l-xu (li-l-xu) wrote : | #72 |
(In reply to Mika Kuoppala from comment #69)
> The current igt to explore this bug is at:
> http://
>
> Please test rendercoords with the new patch attached.
Firstly,I have tried to patch the [PATCH] sna/kgem: Gen8 blt broken when dest base offset has bit 4 set, but failed,it isn't a kernel patch ,right?
And then with the new igt patch attached,case can run,and shows as follows:
IGT-Version: 1.8-gaa63fc7 (x86_64) (Linux: 3.18.0-
Aperture size is 4096 MiB
Total RAM is 3795 MiB
Subtest input-checking: SUCCESS (0.000s)
Subtest usage-restrictions: SUCCESS (0.000s)
Subtest invalid-
Subtest invalid-
Subtest forked-access: SUCCESS (0.001s)
Subtest forbidden-
Testing unsynchronized mappings...
Subtest create-
Subtest unsync-overlap: SUCCESS (0.000s)
Subtest unsync-unmap: SUCCESS (0.001s)
Subtest unsync-
Subtest unsync-
Using 2x2730 1MiB buffers
Verifying initialisation...
Cyclic blits cpu->gpu, forward...
Cyclic blits gpu->cpu, backward...
Random blits...
Subtest coherency-unsync: SUCCESS (445.795s)
Subtest dmabuf-unsync: SUCCESS (0.027s)
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest forked-
Subtest swapping-
Estimated that we need 4298117120 bytes for the test, but only have 3903848448 bytes available (RAM)
Test requirement not met in function minor_evictions, file eviction_
Test requirement: intel_check_
Subtest minor-unsync-
Estimated that we need 4613746688 bytes for the test, but only have 3903848448 bytes available (RAM)
Test requirement not met in function major_evictions, file eviction_
Test requirement: intel_check_
Subtest major-unsync-
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #73 |
Created attachment 109657
Enforce alignment for new buffers
Also we should do something like this... Definitely need the buffer tweak, but we might get away with the general bo as it currently stands, but it seems silly to risk it.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #74 |
(In reply to Mika Kuoppala from comment #68)
> Created attachment 109634 [details] [review]
> [PATCH] sna/kgem: Gen8 blt broken when dest base offset has bit 4 set
>
> Updated patch with more strict restriction to dest offset
Woah... Any alignment with bit 4 set is broken? ARGH.
In freedesktop.org Bugzilla #79053, Mika-kuoppala (mika-kuoppala) wrote : | #75 |
(In reply to Li Xu from comment #70)
> (In reply to Mika Kuoppala from comment #69)
> > The current igt to explore this bug is at:
> > http://
> >
> > Please test rendercoords with the new patch attached.
> Firstly,I have tried to patch the [PATCH] sna/kgem: Gen8 blt broken when
> dest base offset has bit 4 set, but failed,it isn't a kernel patch ,right?
> And then with the new igt patch attached,case can run,and shows as follows:
The patch is for xf86-video-intel. Please test.
In freedesktop.org Bugzilla #79053, Mika-kuoppala (mika-kuoppala) wrote : | #76 |
(In reply to Chris Wilson from comment #72)
> (In reply to Mika Kuoppala from comment #68)
> > Created attachment 109634 [details] [review] [review]
> > [PATCH] sna/kgem: Gen8 blt broken when dest base offset has bit 4 set
> >
> > Updated patch with more strict restriction to dest offset
>
> Woah... Any alignment with bit 4 set is broken? ARGH.
And it applies to source also. Any alignment on either source or destination base offset with bit 4 set will fail.
In freedesktop.org Bugzilla #79053, Xunx-fang (xunx-fang) wrote : | #77 |
(In reply to Mika Kuoppala from comment #68)
> Created attachment 109634 [details] [review]
> [PATCH] sna/kgem: Gen8 blt broken when dest base offset has bit 4 set
>
> Updated patch with more strict restriction to dest offset
It passes with the patch.
In freedesktop.org Bugzilla #79053, Chris Wilson (ickle) wrote : | #78 |
commit 3a22b6f6d55a5b1
Author: Mika Kuoppala <email address hidden>
Date: Wed Nov 19 15:10:05 2014 +0200
sna: gen8 BLT broken when address has bit 4 set
With bit 4 set in address, the gen8 blitter fails and blits errorneously
into the cacheline preceeding the destination and similarly when reading fro
the source, corrupting memory.
v2: Update the destination base offset pattern as revealed
by igt/tests/
v3: Check base address as well
Bugzilla: https:/
Cc: Chris Wilson <email address hidden>
Tested-by: <email address hidden> [v2]
Signed-off-by: Mika Kuoppala <email address hidden>
commit 8dee52997891108
Author: Chris Wilson <email address hidden>
Date: Wed Nov 19 13:38:20 2014 +0000
sna: Add more checks and asserts for BLT capable bo
Before we use the BLT for core acceleration, double check that we can.
This should catch the case where we attempt to operate on SHM pixmaps
which do not meet the restrictions.
Signed-off-by: Chris Wilson <email address hidden>
commit a90cc3b3889fafb
Author: Chris Wilson <email address hidden>
Date: Tue Nov 18 08:37:25 2014 +0000
sna: Tweak alignment constraints on gen8 to allow BLT
The previous commits prevent us from using the BLT if the destination
address is misaligned. Honour that restriction when creating buffers as
well, so that they are always usuable by the BLT.
Signed-off-by: Chris Wilson <email address hidden>
In freedesktop.org Bugzilla #79053, Xunx-fang (xunx-fang) wrote : | #79 |
Verified it on latest xf86-video-intel.
Changed in xserver-xorg-video-intel (Ubuntu Vivid): | |
assignee: | nobody → Timo Aaltonen (tjaalton) |
status: | New → In Progress |
Launchpad Janitor (janitor) wrote : | #1 |
This bug was fixed in the package xserver-
---------------
xserver-
* Merge from debian experimental (LP: #1401784, #1401788)
* Drop upstream patches.
xserver-
* New upstream snapshot.
xserver-
[ Vincent Cheng ]
* New upstream prerelease 2.99.916.
- sna: Add the current CRTC mode last (Closes: #750605)
* Update debian/copyright. (Closes: #730643)
* Revert to source format 1.0.
[ Laurent Bigonville ]
* debian/
i915-kms.conf on upgrade. (Closes: #713340)
-- Timo Aaltonen <email address hidden> Fri, 12 Dec 2014 09:24:52 +0200
Changed in xserver-xorg-video-intel (Ubuntu Vivid): | |
status: | In Progress → Fix Released |
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → Critical |
status: | Unknown → Fix Released |
Chris J Arges (arges) wrote : | #80 |
Timo,
Can you fill out the an SRU justification to make it clear why this fix needs to be SRUed? In addition I see three patches identified in (https:/
description: | updated |
description: | updated |
Timo Aaltonen (tjaalton) wrote : | #81 |
right, it needs two of them one of which doesn't apply without manual backporting.. so I'll just pull all three. Drop the current upload and I'll do another one.
description: | updated |
Chris J Arges (arges) wrote : Please test proposed package | #82 |
Hello Timo, or anyone else affected,
Accepted xserver-
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Changed in xserver-xorg-video-intel (Ubuntu Trusty): | |
status: | New → Fix Committed |
tags: | added: verification-needed |
Changed in xserver-xorg-video-intel (Ubuntu Utopic): | |
status: | New → Fix Committed |
Chris J Arges (arges) wrote : | #83 |
Hello Timo, or anyone else affected,
Accepted xserver-
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
tags: |
added: verification-done-trusty verification-done-utopic removed: verification-needed |
Launchpad Janitor (janitor) wrote : | #84 |
This bug was fixed in the package xserver-
---------------
xserver-
[ Timo Aaltonen ]
* Added patches:
- disable-dri3.diff: Disable DRI3. (LP: #1401784)
- sna-fix-
sna-
sna-
Fix GEN8 BLT with 4bit address. (LP: #1401788)
[ Maarten Lankhorst ]
* Fix rotating external display with optimus results in corruption.
- fix-sna-
-- Maarten Lankhorst <email address hidden> Tue, 13 Jan 2015 17:16:49 +0100
Changed in xserver-xorg-video-intel (Ubuntu Utopic): | |
status: | Fix Committed → Fix Released |
Scott Kitterman (kitterman) wrote : Update Released | #85 |
The verification of the Stable Release Update for xserver-
Launchpad Janitor (janitor) wrote : | #86 |
This bug was fixed in the package xserver-
---------------
xserver-
[ Timo Aaltonen ]
* sna-fix-
sna-
sna-
- Fix GEN8 BLT with 4bit address. (LP: #1401788)
[ Maarten Lankhorst ]
* Fix regression with external displays on sna. (LP: #1405325)
* Fix rotating external display with optimus results in corruption.
- fix-sna-
-- Maarten Lankhorst <email address hidden> Tue, 13 Jan 2015 17:14:19 +0100
Changed in xserver-xorg-video-intel (Ubuntu Trusty): | |
status: | Fix Committed → Fix Released |
Created attachment 99556
dmesg
System Environment: ------- ------- ----- libdrm- 2.4.54- 9-g8fc62ca8ac01 0659023bb63c475 9eb683de4f9af c524f3ef9155cab a6cd4f9fc724854 26b1da76fd (master) xorg-server- 1.15.99. 902-91- g01e18af17f8dc9 1451fbd09020490 45afd1cea7e intel:( master) 2.99.911- 178-g197ab0cda0 6c44aa1a2b17bf6 9ac08612811b107 35e70cb9b9c77df b99fb370e319ed5 01f0c31b17 1d1b8da1284f7f9 18733db79428f09 af38d7e14a c1216342bfcdbf2 678ec29860
-------
Platform: Broadwell
Libdrm: (master)
Mesa: (master)
Xserver:
Xf86_video_
Libva: (staging)
Libva_intel_driver: (staging)
Kernel: (drm-intel-nightly) 36765340cb068de
Bug detailed description: ------- ------- ------- -
-------
It fails and causes X server shutdown. It happens on Broadwell with -queued and -nightly kernel, works well on -fixes kernel.
The latest known good commit: 229b0489aa75a8c 51d2f2e124329d3 ac326f326d 790a72bd5dc0690 9617432352
The latest known bad commit: bc76e320f21f8bd
output:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Found server-supported format: a8
Found server-supported format: a8r8g8b8
Found server-supported format: x8r8g8b8
Found server-supported format: b8g8r8a8
Found server-supported format: b8g8r8x8
Found server-supported format: r8g8b8
Found server-supported format: b8g8r8
Found server-supported format: r5g5b5
Found server-supported format: b5g5r5
Found server-supported format: x1r5g5b5
Found server-supported format: x1b5g5r5
Found server-supported format: r5g6b5
Found server-supported format: b5g6r5
Found server-supported format: x8b8g8r8
Found server-supported format: x2r10g10b10
Found server-supported format: x2b10g10r10
Beginning dest coords test
dst coords test error of 255.0000 at (0, 0) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 2) --
R G B A
got: 1.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (0, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (1, 1) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 3) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (1, 4) --
R G B A
got: 0.000 0.000 0.000 1.000
expected: 1.000 1.000 1.000 1.000
dst coords test error of 255.0000 at (2, 1) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 2) --
R G B A
got: 1.000 1.000 1.000 1.000
expected: 1.000 0.000 0.000 1.000
dst coords test error of 255.0000 at (2, 3) --
R G B ...