Bug 111256

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* GLK: igt@prime_busy@wait-hang-vebox - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110! 
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-glk7/igt@prime_busy@wait-hang-vebox.html

Looks very innocuous. There's at least one change pending to i915_active that will affect this, so watch this space?

Setting priority to low based on Chris' comment.

A CI Bug Log filter associated to this bug has been updated:

{- GLK: igt@prime_busy@wait-hang-vebox - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!  -}
{+ SNB GLK: igt@prime_busy@wait-hang-vebox - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!  +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6601/shard-snb6/igt@gem_eio@in-flight-suspend.html

A CI Bug Log filter associated to this bug has been updated:

{- SNB GLK: igt@prime_busy@wait-hang-vebox - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!  -}
{+ SNB GLK: igt@prime_busy@wait-hang-vebox|igt@gem_eio@in-flight-suspend - dmesg-warn - kernel BUG at ./drivers/gpu/drm/i915/intel_wakeref.h:110!  +}


  No new failures caught with the new filter

No causal link, but 

commit d8af05ff38ae7a42819b285ffef314942414ef8b (HEAD -> drm-intel-next-queued, drm-intel/for-linux-next, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 2 11:00:15 2019 +0100

    drm/i915: Allow sharing the idle-barrier from other kernel requests
    
    By placing our idle-barriers in the i915_active fence tree, we expose
    those for reuse by other components that are issuing requests along the
    kernel_context. Reusing the proto-barrier active_node is perfectly fine
    as the new request implies a context-switch, and so an opportune point
    to run the idle-barrier. However, the proto-barrier is not equivalent
    to a normal active_node and care must be taken to avoid dereferencing the
    ERR_PTR used as its request marker.

is likely related. Watch this space.

commit c7302f204490f3eb4ef839bec228315bcd3ba43f (drm-intel/for-linux-next, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 8 21:27:58 2019 +0100

    drm/i915: Defer final intel_wakeref_put to process context
    
    As we need to acquire a mutex to serialise the final
    intel_wakeref_put, we need to ensure that we are in process context at
    that time. However, we want to allow operation on the intel_wakeref from
    inside timer and other hardirq context, which means that need to defer
    that final put to a workqueue.
    
    Inside the final wakeref puts, we are safe to operate in any context, as
    we are simply marking up the HW and state tracking for the potential
    sleep. It's only the serialisation with the potential sleeping getting
    that requires careful wait avoidance. This allows us to retain the
    immediate processing as before (we only need to sleep over the same
    races as the current mutex_lock).
    
    v2: Add a selftest to ensure we exercise the code while lockdep watches.
    v3: That test was extremely loud and complained about many things!
    v4: Not a whale!
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295
    References: https://bugs.freedesktop.org/show_bug.cgi?id=111245
    References: https://bugs.freedesktop.org/show_bug.cgi?id=111256
    Fixes: 18398904ca9e ("drm/i915: Only recover active engines")
    Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190808202758.10453-1-chris@chris-wilson.co.uk

Probably.

The reproduction rate of this issue is once in 8.3 runs. Last seen CI_DRM_6601_full (3 months, 4 weeks old) and current run is 7435. Archiving this bug.

The CI Bug Log issue associated to this bug has been archived.

New failures matching the above filters will not be associated to this bug anymore.