| Summary: | [hsw edp regression (see comment #21)]: constant screen flickering after KMS which correlates with CPU load | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Maxim Konyushikhin <konush> |
| Component: | DRM/Intel | Assignee: | Mika Kuoppala <mika.kuoppala> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | highest | CC: | intel-gfx-bugs, konush, narthana.epa+freedesktop |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 98310 [details]
video which shows screen flickering
Created attachment 98311 [details]
partial dmesg with drm.debug=0xe
Forgot to say that my laptop has 12Gb of RAM and is booted using EFI. Created attachment 98312 [details]
intel_reg_dumper output
dmesg output:
[ 589.886383] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 589.886393] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[ 589.886401] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 589.886409] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[ 589.886412] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 589.886415] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[ 589.886426] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to 44004
[ 589.886429] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 44004
[ 589.886443] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to c400c
[ 589.886554] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 589.886555] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to 4400c
[ 589.886616] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 589.886642] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
Tested on kernel-3.15-rc3: no difference. kernel-3.9.11 and older - the issue is absent; kernel 3.10.0 and newer - the issue is present. (In reply to comment #6) > kernel-3.9.11 and older - the issue is absent; > kernel 3.10.0 and newer - the issue is present. If you are able to bisect the first bad commit, it will help us root cause this faster. I digged out the first bad commit patch-by-patch. In particular, this page is interesting: http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-next&qt=grep&q=&ofs=55250 The last good commit was "lguest: improve code readability in lg_cpu_start". The first bad commit is "drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth", here is a direct link: http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=67d411ddb9def691572cd5ad0ee2991510d860d2 I apologize for forgetting to resolve git branches. In fact, a relevant page is here: http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-next&id=bae3699182027525d92b97d904578a533264b242&qt=committer&q=Vetter and the first bad commit is "drm/i915: convert DP autodither code to new infrastructure". The patch can be found here: http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=3600836585e3fdef0a1410d63fe5ce4015007aac (In reply to comment #9) > and the first bad commit is "drm/i915: convert DP autodither code to new > infrastructure". The patch can be found here: > http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel- > next&id=3600836585e3fdef0a1410d63fe5ce4015007aac Please attach intel_reg_dumper output for 1) running the bad commit commit 3600836585e3fdef0a1410d63fe5ce4015007aac Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure and 2) the immediately preceding commit that I presume is good commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw and finally 3) running current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel. I'm sorry if this is a bit laborous, but this seems hard to figure out otherwise. Created attachment 98551 [details]
intel_reg_dumper output: the last good commit
Created attachment 98552 [details]
intel_reg_dumper output: the first bad commit
Created attachment 98553 [details]
intel_reg_dumper output: the nightly commit d8aaef4e612a004325293ddf9b7f36cf87d991f0
Just is case: for the "last good"/"first bad" linux kernel, the screen resolution is correct, but framebuffer occupies only approximately 2/3 of height and width of the screen. For the nightly kernel, this problem is absent. For the last good kernel: [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 141000KHz [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24 [drm:intel_dp_compute_config], DP link bw required 338400 available 432000 For the first bad & the nightly kernel: [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 141000KHz [drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18 [drm:intel_dp_compute_config], DP link bw required 253800 available 259200 Might the problem be related to bpp which changed from 24 to 18? I forced bpp to 24:
diff -Naur drivers1/gpu/drm/i915/intel_display.c drivers2/gpu/drm/i915/intel_display.c
--- drivers1/gpu/drm/i915/intel_display.c 2014-05-06 14:08:26.000000000 +0200
+++ drivers2/gpu/drm/i915/intel_display.c 2014-05-06 14:09:26.000000000 +0200
@@ -8188,6 +8188,8 @@
pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
}
+ pipe_config->pipe_bpp = 24;
+
/* Clamp bpp to 8 on screens without EDID 1.4 */
if (connector->base.display_info.bpc == 0 && bpp > 24) {
DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of 24\n",
diff -Naur drivers1/gpu/drm/i915/intel_dp.c drivers2/gpu/drm/i915/intel_dp.c
--- drivers1/gpu/drm/i915/intel_dp.c 2014-05-06 14:22:16.000000000 +0200
+++ drivers2/gpu/drm/i915/intel_dp.c 2014-05-06 14:23:29.000000000 +0200
@@ -748,6 +748,8 @@
bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
}
+ bpp = 24;
+
for (; bpp >= 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
Screen flickering disappeared, but I see sharp color transitions on pictures with smoothly changing color. So bpp=18 was correct, thereas some other parameters were problematic. Probably, those lines are important:
[ 1.332972] [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24
[ 1.332973] [drm:intel_dp_compute_config], DP link bw required 338400 available 432000
A problem of bandwidth?
The following temporary workaround prevents screen flickering:
--- intel_dp.c.orig 2014-05-06 16:36:52.969995358 +0200
+++ intel_dp.c 2014-05-06 16:45:11.209995061 +0200
@@ -749,7 +749,7 @@
}
for (; bpp >= 6*3; bpp -= 2*3) {
- mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
+ mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp +6);
for (clock = 0; clock <= max_clock; clock++) {
for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
but now I get the following messages when running an OpenGL application:
[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3663 at drivers/gpu/drm/i915/intel_display.c:8853 check_crtc_state+0x65f/0xb50()
pipe state doesn't match!
I am thinking that if we hit too close to the boundary in your case.
Could you give this a spin:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34ed143..6310543 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -819,7 +819,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
link_avail = intel_dp_max_data_rate(link_clock,
lane_count);
- if (mode_rate <= link_avail) {
+ if (mode_rate * 11 <= link_avail * 10) {
goto found;
}
}
This patch works, no screen flickering. [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 18 [drm:intel_dp_compute_config], DP link bw required 253800 available 432000 [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1 Can you please retest with latest drm-intel-fixes from http://cgit.freedesktop.org/drm-intel I specifically wonder about the vbt-based edp settings. I tried drm-intel-nightly 6090912409714e19c6f5729952d23b457ad41712: no screen flickering, but the kernel panics right after KMS (I had about two seconds to do tests). Attaching a photo with the kernel message. Do you want me to test a particular earlier version of drm-intel-nightly? Created attachment 99158 [details]
kernel panic, drm-intel-6090912409714e19c6f5729952d23b457ad41712
(In reply to comment #20) > Can you please retest with latest drm-intel-fixes from > > http://cgit.freedesktop.org/drm-intel > > I specifically wonder about the vbt-based edp settings. Ugh, that's bad. Can you please try to bisect where this regression with the kernel panic was introduced? No more hangs with the latest intel-drm-nightly, no screen flickering. Thanks and sorry for the delay! Please, let me know if you want me to test anything else. Closing is all that's needed, thanks for the report and testing. Closing resolved+fixed, verification done by Reporter. |
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.
Created attachment 98309 [details] example of screen flickering Dear developers, Right after i915 sets native display resolution, boot screen starts to flicker. Between flickers, text on the screen is sharp, colors are not distorted anyhow. If there is no CPU activity, this flickering is almost absent, thereas the amount of screen flickering is proportional to system load. For instance, command "yes >/dev/null" leads to a lot of flickering (see examples attached). The very same flickering happens if X is running. In any other aspect my system runs normally. The issue seems not to be related to MTRR register setup, but it may be related to CPU/GPU transitions between various power states. The system is Thinkpad t440s, i7-4600U, 1920x1080 touchscreen and additional discrete NVidia GeForce GT 730M graphics card (which was disabled). Tested with kernel-3.12.18 and kernel-3.15-rc2.