Bug 66511 - [ivb regression] WARNING: at i915/intel_display.c:1656 ironlake_crtc_disable
Summary: [ivb regression] WARNING: at i915/intel_display.c:1656 ironlake_crtc_disable
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-02 16:40 UTC by Jiri Slaby
Modified: 2017-07-24 22:57 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
dmesg (118.63 KB, text/plain)
2013-07-02 16:40 UTC, Jiri Slaby 		no flags Details
Warning and subsequent Oops (24.41 KB, text/plain)
2013-07-30 08:17 UTC, Roel Teuwen 		no flags Details
View All

Description Jiri Slaby 2013-07-02 16:40:18 UTC 
Created attachment 81893 [details]
dmesg

I have two i915 warnings today with freshly booted 3.10. I think they occured during resume from disk... 

WARNING: at drivers/gpu/drm/i915/intel_display.c:1656 ironlake_crtc_disable

and

WARNING: at drivers/gpu/drm/i915/intel_display.c:1091 assert_pch_pll
Comment 1 Daniel Vetter 2013-07-02 17:18:32 UTC 
Yeah, that's already reported at

https://lkml.org/lkml/2013/6/25/552

Should be fixed in 3.11/drm-next, can you please confirm that?

The backport is too invasive and thus far we haven't seen a case where this state tracking mismatch resulted in real issue, so I think I'll just disable the WARN in 3.10.
Comment 2 Roel Teuwen 2013-07-30 08:15:51 UTC 
As a data point, I'm also getting this warning consistently on every cold boot, followed by an Oops every other boot when X starts.
Comment 3 Roel Teuwen 2013-07-30 08:17:10 UTC 
Created attachment 83277 [details]
Warning and subsequent Oops
Comment 4 Daniel Vetter 2013-08-04 21:30:04 UTC 
(In reply to comment #3)
> Created attachment 83277 [details]
> Warning and subsequent Oops

That one looks much more severe since the's a follow-up Oops.

Roel, can you please file a new bug report for your issue (easier to keep track of things in case they turn out to be different bugs, which is rather likely here)? Please boot your kernel with drm.debug=0xe added to your bootline and attach the complete dmesg (after the Oops happened). Also if the Oops is a regression, attempting a bisect might be really useful.

Thanks, Daniel
Comment 5 Chris Wilson 2013-08-11 11:28:49 UTC 
Roel, please do grab a complete drm.debug=6 with a recent stable kernel (or preferably drm-intel-nightly) for your oops and file a separate bug.

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.