Created attachment 123021 [details] dmesg Kernel: 4.6.0-040600rc3-generic Architecture: x86_64 Distribution: Ubuntu 14.04 trusty Machine: Thinkpad T440p Connector: VGA I was trying to find a way for my Haswell system (Thinkpad T440p, 20AN0034RT, i5-4300M) to enter deeper power-saving package states (below pc3) and it turned out, that after following actions system indeed goes to pc7: 1. Setting i915.enable_psr=1 2. Setting SATA link_power_management_policy to min_power But immediately after applying these settings the problem occurs. External VGA monitor is no longer usable, as it starts flickering constantly every second during idling. However, when some activity occurs (video playback or some CPU intensive task, for example) flickering stops. Main screen screen is flickering too, but not so hard and is effectively usable as it just becomes black only for a fraction of second and rarely. As in 4.6 PSR is planned to be set enabled by default I decided to report this.
I can confirm similar behavior. PC7 is achieved, which is great. But LVDS panel occasionally flickers (I think it improved for 4.5 over 4.4, i.e. less often, but I may be subjectively wrong). I can also confirm that external docked DP monitor occasionally gets into a flicker mode where it's unusable - flickers too often. In that case, usually `xrandr --off` and then re-doing `xrandr --mode auto` will fix it. So fortunately everything is still quite usable, but acts as a workflow annoyance.
(In reply to Leho Kraav (:macmaN :lkraav) from comment #1) > I can confirm similar behavior. PC7 is achieved, which is great. But LVDS Oops, forgot specs. Kernel: 4.5.1-gentoo Machine: Dell E7440 Haswell Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
Also "fifo_underrun" error messages are appearing each time during external monitor connection, which are obviously directly related to this bug, as they are appearing only when settings leading to this bug are set and not otherwise. [ 559.660256] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B [ 559.660274] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun [ 559.660297] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A [ 559.660309] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
As a temporary solution this bug can be worked around simply by using tlp if you are using external monitor only while working from AC, as SATA link_power_management_policy will be set to max_performance automaticly. However rare flickering of internal screen remains.
The occasional flicker I believe it is a duplication of #95176 The VGA flickering has nothing to do with PSR which is an eDP feature. So, regarding the occasional flicker, could you please check i915.enable_psr=2 and also another boot with i915.enable_psr=3? What kind of gfx environment do you use? gnome x kde? Xorg x Wayland? does anything special triggers the flickering? suspend resume? or after dpms off when display goes off after a while and after comming back? or immediately after booting? Thanks, Rodrigo.
>The VGA flickering has nothing to do with PSR which is an eDP feature. However PSR is triggering this bug somehow. I noticed the following things (about problem with VGA monitor): 1. Problem with VGA monitor completely disappears with i915.enable_psr=2 (and 0, of course, but remains with 1 and 3). 2. VGA monitor flickers only when I'm using two monitors (laptop monitor and VGA monitor). When I use VGA monitor as a single monitor problem not is not happening. 3. Problem starts immediately after I switch link_power_management_policy to min_power and immediately disappears when I switch it back. 4. fifo_underrun messages showing during connection of second monitor only when bug is happening.
>What kind of gfx environment do you use? gnome x kde? Xorg x Wayland? I experienced all of these problems under XFCE and MATE (under Xorg, of course).
Created attachment 123486 [details] untruncated dmesg from boot
Is this issue still seen with latest kernel?
Yes, it's still there, but fortunately the problem has become much less severe over time. During the last time I noticed it severely triggering was when I played YT videos on Firefox on the 3440x1440 59Hz monitor connected via DELL PR02X dock DisplayPort. I'm on DELL E7440 Haswell. As soon as I moved the browser window to laptop screen, flicker stopped. It was like it didn't have enough... something to drive the external display.
(In reply to Leho Kraav (:macmaN :lkraav) from comment #10) > Yes, it's still there, but fortunately the problem has become much less > severe over time. (forgot above, monitor is DELL 3415W) PS the confusing part of it is, the problem doesn't manifest with any regularity for me. I play videos on the external screen very often and majority of the time everything is fine. (PS dropping X and xf86-video-intel in favor of pure wayland + mesa has produced a massive improvement in reducing video stuttering in Firefox, and video performance/workflow stability in general) Historically, back in earlier 4.x series, ever since enable_psr=1 landed (4.5-4.6?), flickering was a regular guest even on the laptop eDP1 display. That was soon after fixed, I haven't seen that happen for a long while now. External screen keeps on occasionally flickering. I think somewhere at 4.7-4.8+ this has also been reduced to bare minimum, where it only rarely disturbs everyday workflow. I'm not sure if also connected to this specific problem, or i915 drm layer in general, but these are the quirks I'm still seeing in 4.9.0-rc6 (haven't had time to upgrade to later, based on changelog not much has changed at relevant layers): 1. when I dock the laptop via DP1, the port gets connected (laptop screen flickers once, as normal) but the external monitor does not take itself out of sleep mode. I have to go to Display settings panel, move monitor arrangement by 1px or whatever so Apply button becomes active, click Apply - boom monitor wakes up. This is not an issue when connecting via HDMI - monitor lights up immediately. So must be something with DP MST negotation? 2. when disconnecting laptop from HDMI, the port doesn't recognize the monitor has been disconnected anymore. Display settings panel shows the external display is still active, laptop lid close doesn't suspend, etc. This is a regression, because HDMI always worked fine for several previous kernel releases (being my "avoid docking problems today" workaround). 3. Flickering we're already discussing here. Still, as of 4.9, all the things have gotten a ton better.
(In reply to Jani Saarinen from comment #9) > Is this issue still seen with latest kernel? As on kernel 4.8.12 I still have this bug on my setup (Thinkpad T440p, external monitor connected to VGA port). In my case it is triggered when two following conditions are satisfied: 1. i915.enable_psr=1 (current kernel default) 2. Setting SATA link_power_management_policy to min_power (automatically set by TLP when cable is disconnected) When i915.enable_psr=2 bug is NOT happening.
(In reply to dnord from comment #12) > (In reply to Jani Saarinen from comment #9) > > Is this issue still seen with latest kernel? > > As on kernel 4.8.12 I still have this bug on my setup (Thinkpad T440p, > external monitor connected to VGA port). In my case it is triggered when two > following conditions are satisfied: > 1. i915.enable_psr=1 (current kernel default) > 2. Setting SATA link_power_management_policy to min_power (automatically set > by TLP when cable is disconnected) > When i915.enable_psr=2 bug is NOT happening. dnord, the following submitted patch https://patchwork.freedesktop.org/patch/127188/ is going to set psr by default because it's known to cause bugs -until we get proper fix. As a general rule, we really don't recommend setting any i915 options to enable or disable features.
We just merged a patch to disable PSR by default: commit 2ee7dc497e348eecbb82adbb1ea9e9a7e29fe921 drm/i915: disable PSR by default on HSW/BDW This commit is marked for inclusion in the stable Kernels, so it should reach your Linux distribution at some point soon. Thank you for your bug report. In case you think the problem still happens, please feel free to reopen the 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.