Untested, but does the following patch solve the problem?  The immediate bug is that we don't drop locks in the error case.  But I'm unclear why we're hitting the error condition in the first place.  Is there a way to get logs with drm.debug out of the CI system?  Or to submit a patch directly to CI for testing without posting it on the mailing list?


diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 391cc7f..075df0c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15317,7 +15317,7 @@ retry:
 
        state = drm_atomic_helper_duplicate_state(dev, &ctx);
        if (WARN_ON(IS_ERR(state)))
-               return;
+               goto fail;
 
        ret = intel_atomic_check(dev, state);
        if (ret) {
@@ -15345,6 +15345,7 @@ retry:
        }
 
        drm_atomic_state_free(state);
+fail:
        drm_modeset_drop_locks(&ctx);
        drm_modeset_acquire_fini(&ctx);
 }

Fixup summary, accidentally typed SKL instead of SNB.

My above patch/comment was actually intended for bug 93666; disregard for this defect since it likely isn't related to underruns.

If I'm reading the CI details correctly, it's not just SNB that gets the underruns, but also ILK and IVB.  However HSW/BDW, which use pretty much the same watermark logic and code, are fine.  I'll take a look to see if I can figure out the source of the problems.  Unfortunately I don't have any of these platforms at the moment so debugging is somewhat challenging.

(In reply to Matt Roper from comment #3)
> My above patch/comment was actually intended for bug 93666; disregard for
> this defect since it likely isn't related to underruns.
> 
> If I'm reading the CI details correctly, it's not just SNB that gets the
> underruns, but also ILK and IVB.  However HSW/BDW, which use pretty much the
> same watermark logic and code, are fine.  I'll take a look to see if I can
> figure out the source of the problems.  Unfortunately I don't have any of
> these platforms at the moment so debugging is somewhat challenging.

Yeah, I made the bug report before Tomi restored machines to operability (due to the ww mutex deadlock that killed them).

Note: On ivb fifo underrun and crc interrupts are shared, so if a fifo underrun happens that also kills the crc. That explains the failures.

Tried to repro here, somehow couldn't :(

Bisected on my snb to

commit 396e33ae204f52abebec9e578f44c749305500f4
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Jan 6 11:34:30 2016 -0800

    drm/i915: Add two-stage ILK-style watermark programming (v10)

Created attachment 121068 [details]
dmesg with drm.debug=0xe set before starting the test

Interesting new observatin I've just made: I can only repro the fifo underrun once per pipe on my snb: First on boot-up on pipe A, then once more with an igt on pipe B. Reloading the module resets this, and I can repro once more.

I can't really reconcile this with the CI results since I thought CI runtime ordering of testcases isn't that stable ... but assuming it's indeed only the first time we use a pipe: Some bug in the initial setup that breaks the wm code?

Created attachment 121170 [details]
wm after boot, pipe A underrun from boot-up

Created attachment 121171 [details]
wm after boot, pipe B underrun due to test

This was fixed a while back by revert:
  https://patchwork.freedesktop.org/patch/71064/

A new version of the problematic patch that should solve the issue being reported here has been posted but not yet merged:
  https://patchwork.freedesktop.org/patch/74800/

https://patchwork.freedesktop.org/patch/74800/ code changes are in drm-intel-nightly as today. Closing.