Bug 109580

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

### New filters associated

* BLB PNV: igt@gem_ringfill@basic-default-hang - dmesg-fail -  Failed assertion: __gem_execbuf(fd, execbuf) == 0
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_204/fi-blb-e6850/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_204/fi-pnv-d510/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_207/fi-blb-e6850/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_208/fi-blb-e6850/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_208/fi-pnv-d510/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_209/fi-blb-e6850/igt@gem_ringfill@basic-default-hang.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_209/fi-pnv-d510/igt@gem_ringfill@basic-default-hang.html

About the only thing of real note there is the issue that execbuf sees the temporary wedging.

commit c41166f9a145f1c4ce2961b338f9b57495ace4b5 (HEAD -> drm-intel-next-queued, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Feb 20 14:56:37 2019 +0000

    drm/i915: Beware temporary wedging when determining -EIO
    
    At a few points in our uABI, we check to see if the driver is wedged and
    report -EIO back to the user in that case. However, as we perform the
    check and reset asynchronously (where once before they were both
    serialised by the struct_mutex), we may instead see the temporary wedging
    used to cancel inflight rendering to avoid a deadlock during reset
    (caused by either us timing out in our reset handler,
    i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare
    for a stuck modeset). If we suspect this is the case, that is we see a
    wedged driver *and* reset in progress, then wait until the reset is
    resolved before reporting upon the wedged status.
    
    v2: might_sleep() (Mika)
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190220145637.23503-1-chris@chris-wilson.co.uk

(In reply to Chris Wilson from comment #3)
> commit c41166f9a145f1c4ce2961b338f9b57495ace4b5 (HEAD ->
> drm-intel-next-queued, drm-intel/drm-intel-next-queued)
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Feb 20 14:56:37 2019 +0000
> 
>     drm/i915: Beware temporary wedging when determining -EIO
>     
>     At a few points in our uABI, we check to see if the driver is wedged and
>     report -EIO back to the user in that case. However, as we perform the
>     check and reset asynchronously (where once before they were both
>     serialised by the struct_mutex), we may instead see the temporary wedging
>     used to cancel inflight rendering to avoid a deadlock during reset
>     (caused by either us timing out in our reset handler,
>     i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare
>     for a stuck modeset). If we suspect this is the case, that is we see a
>     wedged driver *and* reset in progress, then wait until the reset is
>     resolved before reporting upon the wedged status.
>     
>     v2: might_sleep() (Mika)
>     
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>     Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>     Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20190220145637.23503-1-
> chris@chris-wilson.co.uk

Thanks, seems to have done the trick as it was seen 7 times in 5 runs, and now not seen for 28 runs!

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.