Bug 105359 - kms_frontbuffer_tracking - FBC disabled
Summary: kms_frontbuffer_tracking - FBC disabled
Status: RESOLVED DUPLICATE of bug 108040
Alias: None
Product: DRI
Classification: Unclassified
Component: IGT (show other bugs)
Version: DRI git
Hardware: Other All
: medium enhancement
Assignee: Default DRI bug account
QA Contact:
Whiteboard: ReadyForDev
Depends on:
Reported: 2018-03-06 08:12 UTC by Marta Löfstedt
Modified: 2019-02-25 10:00 UTC (History)
1 user (show)

See Also:
i915 platform: SKL
i915 features: display/FBC

result files for various disp interfaces (4.33 MB, application/gzip)
2018-03-06 08:12 UTC, Marta Löfstedt
no flags Details

Description Marta Löfstedt 2018-03-06 08:12:36 UTC
Created attachment 137813 [details]
result files for various disp interfaces
Comment 1 Marta Löfstedt 2018-03-06 08:19:11 UTC
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.
Comment 2 Marta Löfstedt 2018-03-06 08:30:57 UTC
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.
Comment 3 Marta Löfstedt 2018-03-06 09:24:25 UTC
Sent up an igt patch that will skip the test if FBC was disabled by previous error.
Comment 4 Marta Löfstedt 2018-03-06 12:40:00 UTC

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);

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.
Comment 5 Marta Löfstedt 2018-03-06 13:44:39 UTC
very funny PW results on shards basically all fbc related frontbuffer_tracking tests are skipped.
Comment 6 Marta Löfstedt 2018-03-07 11:38:18 UTC
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
FBC disabled: no suitable CRTC for FBC
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.
Comment 7 Petri Latvala 2019-02-25 10:00:51 UTC

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

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.