Bug 78248 - [BDW GT3 Bisected]igt/gem_render_copy costs long time to execute
Summary: [BDW GT3 Bisected]igt/gem_render_copy costs long time to execute
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Daniel Vetter
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-04 09:14 UTC by Guo Jinxian
Modified: 2017-10-06 14:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (90.18 KB, text/plain)
2014-05-04 09:14 UTC, Guo Jinxian
no flags Details

Description Guo Jinxian 2014-05-04 09:14:31 UTC
Created attachment 98410 [details]
dmesg

*System Environment:
--------------------------
Platform: BDW GT3
kernel: 
-nightly: 08ce6614d07dd1e426109672a5e323317c8d6ec7(fails)
-queued: e5c03ca362819ba8ffbe5674340b61b9cd75de8f (fails)
-fixes: 9bbfd20abe5025adbb0ac75160bd2e41158a9e83 (works)


 *Bug detailed description:
-----------------------------
igt/gem_render_copy costs long time to execute, the test unable to finish in 15 minutes.


It's first time to run this case on GT3

Output:
./gem_render_copy
IGT-Version: 1.6-gc1404e0 (x86_64) (Linux: 3.14.0_drm-intel-next-queued_e5c03c_20140504+ x86_64)


 *Reproduce steps:
---------------------------- 
1. ./gem_render_copy
Comment 1 Chris Wilson 2014-05-05 10:11:03 UTC
You could add driver hang detection. See for example igt/gem_alive, which should detect when the driver is stuck inside its own mutex, or if the GPU is wedged.
Comment 2 Jani Nikula 2014-05-09 07:41:11 UTC
(In reply to comment #0)
> -nightly: 08ce6614d07dd1e426109672a5e323317c8d6ec7(fails)
> -queued: e5c03ca362819ba8ffbe5674340b61b9cd75de8f (fails)
> -fixes: 9bbfd20abe5025adbb0ac75160bd2e41158a9e83 (works)

Does this mean it's a regression from -fixes (3.15-rc) to -nightly? Please bisect.
Comment 3 Chris Wilson 2014-05-09 07:46:38 UTC
It's just the broken BDW GT3 semaphore bug.
Comment 4 Guo Jinxian 2014-05-12 07:43:05 UTC
755376c1d89fb9b2ec24430d793fc4cc1119c0ab is the first bad commit\
Author:     Ben Widawsky <benjamin.widawsky@intel.com>
AuthorDate: Tue Apr 29 14:52:29 2014 -0700
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Wed Apr 30 14:40:58 2014 +0200

    drm/i915: Virtualize the ringbuffer signal func

    This abstraction again is in preparation for gen8. Gen8 will bring new
    semantics for doing this operation.

    While here, make the writes of MI_NOOPs explicit for non-existent rings.
    This should have been implicit before.

    NOTE: This is going to be removed in a few patches.

    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


The commit unable to revert.
Comment 5 Chris Wilson 2014-05-13 14:08:09 UTC
commit d1533379584f8edcfcabb024dffc1b334db8da0f
Author: Oscar Mateo <oscar.mateo@intel.com>
Date:   Fri May 9 13:44:59 2014 +0100

    drm/i915: Ringbuffer signal func for the second BSD ring
    
    This is missing in:
    
    commit 78325f2d270897c9ee0887125b7abb963eb8efea
    Author: Ben Widawsky <benjamin.widawsky@intel.com>
    Date:   Tue Apr 29 14:52:29 2014 -0700
    
        drm/i915: Virtualize the ringbuffer signal func
    
    Looks to me like a rebase side-effect...
    
    Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 6 Guo Jinxian 2014-05-14 03:15:30 UTC
Test on latest -next-queued(70e1e0ec02dfe93650fb2c70824dc81e3eb5b2cc), this bug had fixed. Thanks.
Comment 7 Elizabeth 2017-10-06 14:38:21 UTC
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.