| Summary: | [BAT] igt@kms_frontbuffer_tracking@basic WARN_ON(fbc->active) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Jani Saarinen <jani.saarinen> | ||||
| Component: | DRM/Intel | Assignee: | Marta Löfstedt <marta.lofstedt> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | critical | ||||||
| Priority: | high | CC: | intel-gfx-bugs, przanoni | ||||
| Version: | DRI git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | ReadyForDev | ||||||
| i915 platform: | BDW | i915 features: | display/Other | ||||
| Attachments: |
|
||||||
|
Description
Jani Saarinen
2017-08-30 06:07:55 UTC
This is similar to what is discussed in https://bugs.freedesktop.org/show_bug.cgi?id=101623 However, BUG 101623 was originally (In reply to Marta Löfstedt from comment #1) > This is similar to what is discussed in > https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > However, BUG 101623 was originally OOPS, if you update the title of the bug, bugzilla saves non-finished comment. However, BUG 101623 was originally spuriously hitting the "FBC enabled" fail. Sometime after 2017-08-25 the "FBC enabled" issue can not be reproduced on BDW. Instead there was the BUG 102410 issues. When BUG 102410 was "fixed" we are now hitting these WARN_ONs. Since this is a new thing I believe it is better to discuss this in a bug separate from BUG 101623. Created attachment 133875 [details] [review] take mutex in intel_fbc_init I am doing some experiments with attached patch. So, far I have all kms_frontbuffer_tracking 5 times without hitting the WARN_ON. if I change the patch to grab the mutex just after in was initialized in: void intel_fbc_init(struct drm_i915_private *dev_priv) I didn't reproduce the issue over 10 loops of all kms_frontbuffer_tracking subtests. mäh! I managed to still hit the WARN_ON This is most probably a regression, right? What does git-bisect tell us? (In reply to Paulo Zanoni from comment #6) > This is most probably a regression, right? > > What does git-bisect tell us? If you are referring to "FBC disabled" -> WARN_ON(fbc->active) That started with drm-tip@6e644626945c Marta: for 6e644626945c7c1a7f4d4f83b806b898297846d0 From Ville: "That patch will simply cause more modesets. I think it exposes some pre-existing race conditions in the fbc enable/disable sequences. Chris had some patches, some of which didn't quite make sense, but the current code doesn't really make sense either." (In reply to Jani Saarinen from comment #9) > Marta: for 6e644626945c7c1a7f4d4f83b806b898297846d0 > From Ville: > "That patch will simply cause more modesets. I think it exposes some > pre-existing race conditions in the fbc enable/disable sequences. > Chris had some patches, some of which didn't quite make sense, but the > current code doesn't really make sense either." Yes, this "race" thing is what I tried to communicate to przanoni@gmail.com previously, and also why I did some experiments that didn't pan out. Is there some copying going on with the fbc struct somewhere? After changing display cable on my BDW NUCi5 I can no longer reproduce this issue. Also, it hasn't been seen on the BAT BDWs for a long time |
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.