Bug 105358 - [CI] igt@gem_eio@in-flight* - incomplete - i915_request_retire:390 GEM_BUG_ON(!i915_request_completed(request))
Summary: [CI] igt@gem_eio@in-flight* - incomplete - i915_request_retire:390 GEM_BUG_ON...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Marta Löfstedt
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-06 07:36 UTC by Marta Löfstedt
Modified: 2018-03-19 10:11 UTC (History)
1 user (show)

See Also:
i915 platform: KBL
i915 features: GEM/Other


Attachments

Description Marta Löfstedt 2018-03-06 07:36:27 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3875/shard-kbl4/igt@gem_eio@in-flight-contexts.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3875/shard-kbl7/igt@gem_eio@in-flight.html

From pstore:
<3>[   23.739978] i915_request_retire:390 GEM_BUG_ON(!i915_request_completed(request))
<4>[   23.740062] ------------[ cut here ]------------
<2>[   23.740064] kernel BUG at drivers/gpu/drm/i915/i915_request.c:390!
<4>[   23.740088] invalid opcode: 0000 [#1] PREEMPT SMP PTI
<0>[   23.740095] Dumping ftrace buffer:
Comment 1 Chris Wilson 2018-03-06 08:01:32 UTC
Same basic problem as bug 105341
Comment 2 Marta Löfstedt 2018-03-06 08:04:26 UTC
(In reply to Chris Wilson from comment #1)
> Same basic problem as bug 105341

Yeah, I think so to, but since the backtrace look so different I think it is better to not dup the bugs, or?
Comment 3 Chris Wilson 2018-03-06 08:32:50 UTC
To actually reconstruct the original bug where the guc was executing contexts out of order, you have to disable trickle feeding the guc.
Comment 4 Chris Wilson 2018-03-06 08:33:13 UTC
Oops, wrong bug.
Comment 5 Chris Wilson 2018-03-16 10:18:53 UTC
commit ac697ae8013a7c7301174c9c3b02a92fe418b7ea
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 15 15:10:15 2018 +0000

    drm/i915: Stop engines when declaring the machine wedged
    
    If we fail to reset the GPU, we declare the machine wedged. However, the
    GPU may well still be running in the background with an in-flight
    request. So despite our efforts in cleaning up the request queue and
    faking the breadcrumb in the HWSP, the GPU may eventually write the
    in-flght seqno there breaking all of our assumptions and throwing the
    driver into a deep turmoil, wedging beyond wedged.
    
    To avoid this we ideally want to reset the GPU. Since that has already
    failed, make sure the rings have the stop bit set instead. This is part
    of the normal GPU reset sequence, but that is actually disabled by
    igt/gem_eio to force the wedged state. If we assume the worst, we must
    poke at the bit again before we give up.
    
    v2: Move the intel_gpu_reset() from set-wedged in the reset error path
    into i915_gem_set_wedged() itself. Even if the reset fails (e.g. if it is
    disabled by gem_eio), it still tries to make sure the engines are
    stopped. For i915_gem_set_wedged() callers from outside of i915_reset(),
    this should make sure the GPU is disabled while the driver is marked as
    being wedged.
    
    Testcase: igt/gem_eio
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: Michał Winiarski <michal.winiarski@intel.com>
    Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
    Cc: Michel Thierry <michel.thierry@intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180315151015.22741-1-chris@chris-wilson.co.uk


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.