I have been running all kms tests on a SKL NUCi5 and noticed that while connected to both VGA and HDMI ~150 test failed, but when connected to only HDMI only 2 tests failed. Out of the 1560 failing tests the absolut majority is kms_frontbuffer_tracking failing with "FBC disabled", see bug 101623. 

However, after reboot I could not reproduce the issue when running FBC related kms_frontbuffer_tracking tests manually.

While pruning the test list I noticed that I can run the 
kms_cursor_legacy tests and get a:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

after that I always hit the "FBC disabled" on the FBC related kms_frontbuffer_tracking tests.

cat /sys/kernel/debug/dri/0/i915_fbc_status
FBC disabled: underrun detected

I believe the kms_frontbuffer_tracking tests should check above before failing the test. If it is already disabled why waste time running it.

Sent up an igt patch that will skip the test if FBC was disabled by previous error.

https://patchwork.freedesktop.org/patch/208170/

This caused some discussion. I appears as if devs want a way for user space to reset the "fbc state". I am assuming this also applies for FIFO underrun caused FBC disabled.

I guess that is OK, the only one calling: intel_fbc_handle_fifo_underrun_irq(dev_priv);

is: 
void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
					 enum pipe pipe)

However, this comment in above function:

	/* There's no guarantee that underrun_detected won't be set to true
	 * right after this check and before the work is scheduled, but that's
	 * not a problem since we'll check it again under the work function
	 * while FBC is locked. This check here is just to prevent us from
	 * unnecessarily scheduling the work, and it relies on the fact that we
	 * never switch underrun_detect back to false after it's true. */

so maybe not totally straight forward to implement.

Also, I believe that the massive hit from "FBC disabled" on kasan and shard testlist on BAT is due to this FBC banned by FIFO underrun thing.

very funny PW results on shards basically all fbc related frontbuffer_tracking tests are skipped.

I now found this to be even stranger than anticipated:

checking the i915_FBC_state while running kms tests I have ended up way to many states for this to be sane:
After reboot:
FBC enabled
Compressing: yes

after killing lightdm:
FBC disabled: framebuffer not tiled or fenced

after running some kms tests:
FBC disabled: frontbuffer write
or
FBC disabled: no suitable CRTC for FBC
or
FBC disabled: FBC enabled (active or scheduled)
FBC worker scheduled on vblank 154675, now 154675

My recent idea was to set a warn on disabled:
+       if (strstr(buf, "FBC disabled: "))
+         {
+           igt_warn("%s\n", buf);
+           igt_assert(true);
+         }

This would result in the WARN result if FBC was disabled. This would not save any runtime, but it should stop the confusion if the test failed due to timeout or if due to FBC being disable.

However, when testing above on a SKL NUCi5 system I always end up with WARN on all tests.

*** This bug has been marked as a duplicate of bug 108040 ***