Bug 77263

UXA is meaningless in this context, or rather it means the same as AccelMethod "blt".

Changing component to ease bug tracking.

Have you tried the usual suspects? Disable rc6, ppgtt, hw contexts?

Ben, is this related to the hangs you have been seeing?

I can't remember if I got an error state. I was pretty certain weston was also broken, but Jordan wasn't able to reproduce that.

I suspect it's a different problem. It's completely instant fail.

(In reply to comment #2)
> Have you tried the usual suspects? Disable rc6, ppgtt, hw contexts?

Jinxian, please try disable rc6.

ppgtt: I thought it's not enabled by default?

hw contexts: I don't have idea. Chris can you tell how to disable it?

(In reply to comment #5)
> (In reply to comment #2)
> > Have you tried the usual suspects? Disable rc6, ppgtt, hw contexts?
> 
> Jinxian, please try disable rc6.
> 
> ppgtt: I thought it's not enabled by default?
> 
> hw contexts: I don't have idea. Chris can you tell how to disable it?

Yeah, PPGTT disabled by default, jinxian, you can try disable RC6 firstly.

Disabled RC6 by parameter i915.i915_enable_rc6=0 on latest -nightly(35dc7c8af75a3e5ae52a546978660ce083a6368), this bug still able to reproduce.

Created attachment 97209 [details]
disabled rc6

(In reply to comment #4)
> I can't remember if I got an error state.

Ben and I tried to reproduce this today on my system
in order to grab an error state. Unfortunately, I
couldn't reproduce it.

Jinxian, can you still reproduce the issue with
SNA enabled? If so, can you capture the error
state?

(In reply to comment #9)
> (In reply to comment #4)
> > I can't remember if I got an error state.
> 
> Ben and I tried to reproduce this today on my system
> in order to grab an error state. Unfortunately, I
> couldn't reproduce it.
> 
> Jinxian, can you still reproduce the issue with
> SNA enabled? If so, can you capture the error
> state?

System hung after run glxgear. Unable to capture the error state. Thanks.

(In reply to comment #5)
> (In reply to comment #2)
> > Have you tried the usual suspects? Disable rc6, ppgtt, hw contexts?
> 
> Jinxian, please try disable rc6.
> 
> ppgtt: I thought it's not enabled by default?

Depends on just which branch you test. -nightly should be just the aliasing ppgtt, might be worth just disabling even the aliasing.
 
> hw contexts: I don't have idea. Chris can you tell how to disable it?

It requires a kernel patch to disable. And unfortunately mesa no longer works without contexts, so we can't test the theory that context switching is the root cause - or we could cook up igt/rendercopy to use multiple contexts concurrently and see what happens.

(In reply to comment #9)
> (In reply to comment #4)
> > I can't remember if I got an error state.
> 
> Ben and I tried to reproduce this today on my system
> in order to grab an error state. Unfortunately, I
> couldn't reproduce it.

Were you testing a GT3 system?  If so, there must be some other difference between your test system and Guang's system.  We should try to track down what that difference is.  I talked to Gordon last week, and there seem to be a number of issues that can only be reproduced on some systems... that seem identical to other systems that don't exhibit the problem.

One thing to try is

commit b12bc035fb8ee40bb382e66604e869b729270189
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 22 12:30:29 2014 +0100

    sna: Add a DBG aide to disable hardware execution
    
    Submit a dummy batch so that we still build, submit batches and perform
    relocations, but do not actually invoke the GPU. This can be useful when
    looking at mysterious hardware hangs.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

and

diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 82199a1..68b0917 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -61,7 +61,7 @@ static struct kgem_bo *
 search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned flags);
 
 #define DBG_NO_HW 0
-#define DBG_NO_EXEC 0
+#define DBG_NO_EXEC 1
 #define DBG_NO_TILING 0
 #define DBG_NO_CACHE 0
 #define DBG_NO_CACHE_LEVEL 0

That will isolate the fault in either the driver or the hardware.

In addition to the above test, can you also please try igt/gem_render_copy_redux.

I presume there are no other issues with running i-g-t or X rendering tests?

(In reply to comment #13)
> One thing to try is
> 
> commit b12bc035fb8ee40bb382e66604e869b729270189
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Tue Apr 22 12:30:29 2014 +0100
> 
>     sna: Add a DBG aide to disable hardware execution
>     
>     Submit a dummy batch so that we still build, submit batches and perform
>     relocations, but do not actually invoke the GPU. This can be useful when
>     looking at mysterious hardware hangs.
>     
>     References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> and
> 
> diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> index 82199a1..68b0917 100644
> --- a/src/sna/kgem.c
> +++ b/src/sna/kgem.c
> @@ -61,7 +61,7 @@ static struct kgem_bo *
>  search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned
> flags);
>  
>  #define DBG_NO_HW 0
> -#define DBG_NO_EXEC 0
> +#define DBG_NO_EXEC 1
>  #define DBG_NO_TILING 0
>  #define DBG_NO_CACHE 0
>  #define DBG_NO_CACHE_LEVEL 0
> 
> That will isolate the fault in either the driver or the hardware.


Sorry, I did't find this commit in -nightly -fixes and -next-queued branch, could you tell me, which branch this commit in? Thanks.

(In reply to comment #15)
> I presume there are no other issues with running i-g-t or X rendering tests?

We don't run i-g-t nightly testing on GT3 until now, but we found two bugs on GT3:
    Call trace "intel_pm.c:5686 intel_display_power_put" appears while boot system 
    Rendercheck blend fails 

About X rendering tests, we don't find any GT3 special bug now.

(In reply to comment #16)
> (In reply to comment #13)
> > One thing to try is
> > 
> > commit b12bc035fb8ee40bb382e66604e869b729270189
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Tue Apr 22 12:30:29 2014 +0100
> > 
> >     sna: Add a DBG aide to disable hardware execution
> >     
> >     Submit a dummy batch so that we still build, submit batches and perform
> >     relocations, but do not actually invoke the GPU. This can be useful when
> >     looking at mysterious hardware hangs.
> >     
> >     References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
> >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > and
> > 
> > diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> > index 82199a1..68b0917 100644
> > --- a/src/sna/kgem.c
> > +++ b/src/sna/kgem.c
> > @@ -61,7 +61,7 @@ static struct kgem_bo *
> >  search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned
> > flags);
> >  
> >  #define DBG_NO_HW 0
> > -#define DBG_NO_EXEC 0
> > +#define DBG_NO_EXEC 1
> >  #define DBG_NO_TILING 0
> >  #define DBG_NO_CACHE 0
> >  #define DBG_NO_CACHE_LEVEL 0
> > 
> > That will isolate the fault in either the driver or the hardware.
> 
> 
> Sorry, I did't find this commit in -nightly -fixes and -next-queued branch,
> could you tell me, which branch this commit in? Thanks.

xf86-video-intel.

(In reply to comment #18)
> (In reply to comment #16)
> > (In reply to comment #13)
> > > One thing to try is
> > > 
> > > commit b12bc035fb8ee40bb382e66604e869b729270189
> > > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > > Date:   Tue Apr 22 12:30:29 2014 +0100
> > > 
> > >     sna: Add a DBG aide to disable hardware execution
> > >     
> > >     Submit a dummy batch so that we still build, submit batches and perform
> > >     relocations, but do not actually invoke the GPU. This can be useful when
> > >     looking at mysterious hardware hangs.
> > >     
> > >     References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
> > >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > 
> > > and
> > > 
> > > diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> > > index 82199a1..68b0917 100644
> > > --- a/src/sna/kgem.c
> > > +++ b/src/sna/kgem.c
> > > @@ -61,7 +61,7 @@ static struct kgem_bo *
> > >  search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned
> > > flags);
> > >  
> > >  #define DBG_NO_HW 0
> > > -#define DBG_NO_EXEC 0
> > > +#define DBG_NO_EXEC 1
> > >  #define DBG_NO_TILING 0
> > >  #define DBG_NO_CACHE 0
> > >  #define DBG_NO_CACHE_LEVEL 0
> > > 
> > > That will isolate the fault in either the driver or the hardware.
> > 
> > 
> > Sorry, I did't find this commit in -nightly -fixes and -next-queued branch,
> > could you tell me, which branch this commit in? Thanks.
> 
> xf86-video-intel.

Reset to commit b12bc035fb8ee40bb382e66604e869b729270189 and patched, then build it with latest unstable X11R7, the screen unable to display after start X.

output after start X:
[root@x-bdw08 opt]# xinit &
[1] 4553
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/x-bdw08:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.15.99.902 (1.16.0 RC 2)
Release Date: 2014-04-08
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.3.4-3.fc16.x86_64 x86_64
Current Operating System: Linux x-bdw08 3.15.0-rc2_drm-intel-nightly_11ddb5_20140428+ #2094 SMP Mon Apr 28 11:24:35 CST 2014 x86_64
Kernel command line: BOOT_IMAGE=kernels//nightly_parents/2014_04_28/drm-intel-nightly/11ddb598492d1f97f894495eea398febb41a9eb0/bzImage_x86_64 root=/dev/sda4 drm.debug=0xe modules_path=kernels//nightly_parents/2014_04_28/drm-intel-nightly/11ddb598492d1f97f894495eea398febb41a9eb0/modules_x86_64/lib/modules/3.15.0-rc2_drm-intel-nightly_11ddb5_20140428+ acpi_rsdp=0xab8e1014
Build Date: 27 April 2014  03:48:28PM

Current version of pixman: 0.33.1
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/opt/X11R7/var/log/Xorg.0.log", Time: Thu Dec 12 00:01:32 2013
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xterm: cannot load font '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'

(In reply to comment #14)
> In addition to the above test, can you also please try
> igt/gem_render_copy_redux.

./gem_render_copy_redux
IGT-Version: 1.6-ga595a40 (x86_64) (Linux: 3.15.0-rc2_drm-intel-nightly_11ddb5_20140428+ x86_64)
Expected 0xffff00ff, found 0xfff0ff00 at (502,502)
Aborted (core dumped)

Created attachment 98109 [details]
Xorg.0.log

Created attachment 98110 [details]
ev.list

Created attachment 98111 [details]
gem_render_copy_redux.dmesg

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > (In reply to comment #13)
> > > > One thing to try is
> > > > 
> > > > commit b12bc035fb8ee40bb382e66604e869b729270189
> > > > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Date:   Tue Apr 22 12:30:29 2014 +0100
> > > > 
> > > >     sna: Add a DBG aide to disable hardware execution
> > > >     
> > > >     Submit a dummy batch so that we still build, submit batches and perform
> > > >     relocations, but do not actually invoke the GPU. This can be useful when
> > > >     looking at mysterious hardware hangs.
> > > >     
> > > >     References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
> > > >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > 
> > > > and
> > > > 
> > > > diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> > > > index 82199a1..68b0917 100644
> > > > --- a/src/sna/kgem.c
> > > > +++ b/src/sna/kgem.c
> > > > @@ -61,7 +61,7 @@ static struct kgem_bo *
> > > >  search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned
> > > > flags);
> > > >  
> > > >  #define DBG_NO_HW 0
> > > > -#define DBG_NO_EXEC 0
> > > > +#define DBG_NO_EXEC 1
> > > >  #define DBG_NO_TILING 0
> > > >  #define DBG_NO_CACHE 0
> > > >  #define DBG_NO_CACHE_LEVEL 0
> > > > 
> > > > That will isolate the fault in either the driver or the hardware.
> > > 
> > > 
> > > Sorry, I did't find this commit in -nightly -fixes and -next-queued branch,
> > > could you tell me, which branch this commit in? Thanks.
> > 
> > xf86-video-intel.
> 
> Reset to commit b12bc035fb8ee40bb382e66604e869b729270189 and patched, then
> build it with latest unstable X11R7, the screen unable to display after
> start X.

As expected. Did you run glxgears?

Also have you tried and filed a bug for gem_render_copy?

(In reply to comment #25)
> Also have you tried and filed a bug for gem_render_copy?

bug 78248 was reported to tracked gem_render_copy.

(In reply to comment #24)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > (In reply to comment #16)
> > > > (In reply to comment #13)
> > > > > One thing to try is
> > > > > 
> > > > > commit b12bc035fb8ee40bb382e66604e869b729270189
> > > > > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Date:   Tue Apr 22 12:30:29 2014 +0100
> > > > > 
> > > > >     sna: Add a DBG aide to disable hardware execution
> > > > >     
> > > > >     Submit a dummy batch so that we still build, submit batches and perform
> > > > >     relocations, but do not actually invoke the GPU. This can be useful when
> > > > >     looking at mysterious hardware hangs.
> > > > >     
> > > > >     References: https://bugs.freedesktop.org/show_bug.cgi?id=77263
> > > > >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > 
> > > > > and
> > > > > 
> > > > > diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> > > > > index 82199a1..68b0917 100644
> > > > > --- a/src/sna/kgem.c
> > > > > +++ b/src/sna/kgem.c
> > > > > @@ -61,7 +61,7 @@ static struct kgem_bo *
> > > > >  search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned
> > > > > flags);
> > > > >  
> > > > >  #define DBG_NO_HW 0
> > > > > -#define DBG_NO_EXEC 0
> > > > > +#define DBG_NO_EXEC 1
> > > > >  #define DBG_NO_TILING 0
> > > > >  #define DBG_NO_CACHE 0
> > > > >  #define DBG_NO_CACHE_LEVEL 0
> > > > > 
> > > > > That will isolate the fault in either the driver or the hardware.
> > > > 
> > > > 
> > > > Sorry, I did't find this commit in -nightly -fixes and -next-queued branch,
> > > > could you tell me, which branch this commit in? Thanks.
> > > 
> > > xf86-video-intel.
> > 
> > Reset to commit b12bc035fb8ee40bb382e66604e869b729270189 and patched, then
> > build it with latest unstable X11R7, the screen unable to display after
> > start X.
> 
> As expected. Did you run glxgears?

Yes, The glxgears is able to run, but it unable to display on the monitor. Thanks.

(In reply to comment #20)
> (In reply to comment #14)
> > In addition to the above test, can you also please try
> > igt/gem_render_copy_redux.
> 
> ./gem_render_copy_redux
> IGT-Version: 1.6-ga595a40 (x86_64) (Linux:
> 3.15.0-rc2_drm-intel-nightly_11ddb5_20140428+ x86_64)
> Expected 0xffff00ff, found 0xfff0ff00 at (502,502)
> Aborted (core dumped)

Coredumped unable to reproduce on latest -nightly(08ce6614d07dd1e426109672a5e323317c8d6ec7). Instead, the case unable to finish in 15 minutes.

Who owns the next action on this issue?

There are an absence of bug reports for the basic tests here failing. The tests trying to narrow down the problem in the multi-context case are blocked by the results of those basic tests.

As the hang from c28 has been resolved by d1533379584f8edcfcabb024dffc1b334db8da0f, please retest gem_render_copy_redux. Also you mentioned rendercheck -t blend failing...

(In reply to comment #31)
> As the hang from c28 has been resolved by
> d1533379584f8edcfcabb024dffc1b334db8da0f, please retest
> gem_render_copy_redux. Also you mentioned rendercheck -t blend failing...
The result was passed on latest -next-queued(70e1e0ec02dfe93650fb2c70824dc81e3eb5b2cc)
./gem_render_copy_redux.

IGT-Version: 1.6-g0fee90b (x86_64) (Linux: 3.15.0-rc3_prts_70e1e0_20140514 x86_64)
Subtest normal: SUCCESS
Subtest interruptible: SUCCESS
Subtest flink: SUCCESS
Subtest flink-interruptible: SUCCESS

X still unable to display on latest -next-queued(70e1e0ec02dfe93650fb2c70824dc81e3eb5b2cc)

Rodrigo, can you have a go at reproducing the issues here? Also just check basic i-g-t, then X, then X + GL.

(In reply to comment #34)
> Rodrigo, can you have a go at reproducing the issues here? Also just check
> basic i-g-t, then X, then X + GL.
Chris, do you need any data or testing from QA? which basic i-g-t needing ?

In igt, all the gem ones and those involving rendercopy. For X, just checking that rendercheck -t blend,composite,cacomposite -f a8r8g8b8 work.

(In reply to comment #36)
> In igt, all the gem ones and those involving rendercopy. For X, just
> checking that rendercheck -t blend,composite,cacomposite -f a8r8g8b8 work.
Ok, QA will test and give the feedback.

(In reply to comment #36)
> In igt, all the gem ones and those involving rendercopy. 
I don't think we have any igt failures which only happen on this machine, since 78248 (rendercopy) and 78652 have been fixed.

(In reply to comment #36)
> In igt, all the gem ones and those involving rendercopy. For X, just
> checking that rendercheck -t blend,composite,cacomposite -f a8r8g8b8 work.
For igt, all gem cases and rendercopy can pass. 
For X fails with the command: rendercheck -t blend,composite,cacomposite -f a8r8g8b8 on the latest X11R7.
The Output is:
rendercheck 1.4
Render extension version 0.11
Window format: r8g8b8
Ignoring server-supported format: a8
Found server-supported format: a8r8g8b8
Ignoring server-supported format: x8r8g8b8
Ignoring server-supported format: b8g8r8a8
Ignoring server-supported format: b8g8r8x8
Ignoring server-supported format: r8g8b8
Ignoring server-supported format: b8g8r8
Ignoring server-supported format: r5g5b5
Ignoring server-supported format: b5g5r5
Ignoring server-supported format: x1r5g5b5
Ignoring server-supported format: x1b5g5r5
Ignoring server-supported format: r5g6b5
Ignoring server-supported format: b5g6r5
Ignoring server-supported format: x8b8g8r8
Ignoring server-supported format: x2r10g10b10
Ignoring server-supported format: x2b10g10r10
Beginning blend test on a8r8g8b8
Clear blend test error of 192.0000 at (0, 0) --
           R     G     B     A
got:       0.000 0.000 0.000 0.753
expected:  0.000 0.000 0.000 0.000
src color: 1.00 1.00 1.00 1.00 (a8r8g8b8)
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, dst: a8r8g8b8
Beginning blend test on r8g8b8 window
Out blend test error of 255.0000 at (0, 0) --
           R     G     B     A
got:       1.000 1.000 1.000 1.000
expected:  0.000 0.000 0.000 1.000
src color: 1.00 1.00 1.00 1.00 (a8r8g8b8)
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, dst: r8g8b8 window
Beginning composite mask test on a8r8g8b8
Clear composite test error of 192.0000 at (0, 0) --
           R     G     B     A
got:       0.000 0.000 0.000 0.753
expected:  0.000 0.000 0.000 0.000
src color: 1.00 1.00 1.00 1.00
msk color: 1.00 1.00 1.00 1.00
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, mask: 1x1R a8r8g8b8, dst: a8r8g8b8
Beginning composite mask test on r8g8b8 window
Out composite test error of 255.0000 at (0, 0) --
           R     G     B     A
got:       1.000 1.000 1.000 1.000
expected:  0.000 0.000 0.000 1.000
src color: 1.00 1.00 1.00 1.00
msk color: 1.00 1.00 1.00 1.00
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, mask: 1x1R a8r8g8b8, dst: r8g8b8 window
Beginning composite CA mask test on a8r8g8b8
Clear CA composite test error of 192.0000 at (0, 0) --
           R     G     B     A
got:       0.000 0.000 0.000 0.753
expected:  0.000 0.000 0.000 0.000
src color: 1.00 1.00 1.00 1.00
msk color: 1.00 1.00 1.00 1.00
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, mask: 1x1R a8r8g8b8, dst: a8r8g8b8
Beginning composite CA mask test on r8g8b8 window
Out CA composite test error of 255.0000 at (0, 0) --
           R     G     B     A
got:       1.000 1.000 1.000 1.000
expected:  0.000 0.000 0.000 1.000
src color: 1.00 1.00 1.00 1.00
msk color: 1.00 1.00 1.00 1.00
dst color: 1.00 1.00 1.00 1.00
src: 1x1R a8r8g8b8, mask: 1x1R a8r8g8b8, dst: r8g8b8 window
0 tests passed of 6 total
Successful Groups:

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

One difference we have is the gt3 parts are all older steppings. Gordon, Yang Guang, would it be possible to confirm the bug does not happen on gt2 of the same stepping?

Chris, would it help to send you a machine, or do we need to file an internal bug?

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

(In reply to comment #41)
> Chris, would it help to send you a machine, or do we need to file an
> internal bug?

For this, all I hope I would need is remote access. I've been hoping that Rodrigo might be able to spare a few cycles to first confirm the bug on his gt3 and lend a hand or a set of eyes.

Created attachment 100095 [details]
dmesg

(In reply to comment #41)
> One difference we have is the gt3 parts are all older steppings. Gordon,
> Yang Guang, would it be possible to confirm the bug does not happen on gt2
> of the same stepping?
> 

I checked on latest -nightly(d13557ac7bfa813cf31fe750df3895f4b0eb9fbe), this bug does not happen on gt1 and gt2.

(In reply to comment #44)
> Created attachment 100095 [details]
> dmesg
> 
> (In reply to comment #41)
> > One difference we have is the gt3 parts are all older steppings. Gordon,
> > Yang Guang, would it be possible to confirm the bug does not happen on gt2
> > of the same stepping?
> > 
> 
> I checked on latest -nightly(d13557ac7bfa813cf31fe750df3895f4b0eb9fbe), this
> bug does not happen on gt1 and gt2.

Yes, but are the gt1, and gt2 the same stepping as tje gt3?

Chris, any updates from the last few days of work?

(In reply to comment #45)
> (In reply to comment #44)
> > Created attachment 100095 [details]
> > dmesg
> > 
> > (In reply to comment #41)
> > > One difference we have is the gt3 parts are all older steppings. Gordon,
> > > Yang Guang, would it be possible to confirm the bug does not happen on gt2
> > > of the same stepping?
> > > 
> > 
> > I checked on latest -nightly(d13557ac7bfa813cf31fe750df3895f4b0eb9fbe), this
> > bug does not happen on gt1 and gt2.
> 
> Yes, but are the gt1, and gt2 the same stepping as tje gt3?

It works on gt2 with the same stepping of this gt3

Please retest with the latest SNA driver.

(In reply to comment #48)
> Please retest with the latest SNA driver.

The result on latest SNA driver is pass.

Verified on latest -nightly(8148006fc6cc97fea2b792c91c0968a038612355)

Hi Chris, 

The SNA + GT3 error is back.

I couldn't finish the rendercheck tests yet, but please let me know what info should I provide to help you.

Thanks,
Rodrigo.

(In reply to comment #51)
> Hi Chris, 
> 
> The SNA + GT3 error is back.
> 
> I couldn't finish the rendercheck tests yet, but please let me know what
> info should I provide to help you.
> 
> Thanks,
> Rodrigo.

Which error? The original GT3 hard hang or bug 81583? First rollback to last known good (kernel, ddx, mesa, etc) to confirm that it still works in one configuration then see what change causes it to malfunction.

He who can reproduce gets to diagnose...

Ensuring bdw runs is essential to making the 3.0 release.

I have no bdw of my own to check, so what is the current status?

(In reply to comment #55)
> I have no bdw of my own to check, so what is the current status?

On Q3 release kernel(62de88e8e65811010deac5375f8f0d8b14dc4d94).

glxgear will doesn't causes system hang, but glxgear show black on the screen.

(In reply to comment #55)
> I have no bdw of my own to check, so what is the current status?

Note this question should go to Rodrigo. QA had seen system hang gone since comment#49 and closed this bug. But Rodrigo reopened it.

The issue I'm facing on GT3 is better represented by #81583.

Since gpu isn't really hanging when running only glxgears.

So, closing this one for now. GT3 discussion continue there on 81583.

Verified.