Bug 95176 - LCD flickering on Thinkpad T440p (Haswell) with kernel 4.6-rc4 (PSR enabled)
Summary: LCD flickering on Thinkpad T440p (Haswell) with kernel 4.6-rc4 (PSR enabled)
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Jim Bride
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 95124 96277 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-04-27 15:54 UTC by Calvin Walton
Modified: 2019-04-22 20:58 UTC (History)
15 users (show)

See Also:
i915 platform: BDW, HSW
i915 features: display/PSR


Attachments
kernel-drm-debug-log (191.86 KB, text/plain)
2016-04-27 19:36 UTC, Calvin Walton
no flags Details
kernel-drm-debug-log-full-boot (209.20 KB, text/plain)
2016-04-28 13:48 UTC, Calvin Walton
no flags Details
Patch by danvet to fix the issue (3.20 KB, patch)
2016-05-22 18:58 UTC, Peter Frühberger
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Calvin Walton 2016-04-27 15:54:29 UTC
Hi,

Following updating to 4.6-rc kernels (with psr enabled by default), the screen on my ThinkPad T440p (Intel i5-4330M, igpu) has started to flicker occasionally. The screen will go black for around 1-2 frames during times of low activity (it immediately returns to showing the screen again afterwards).

Using the i915.enable_psr=2 or i915.enable_psr=3 makes no difference; the screen flickers occur with both settings. Only setting enable_psr=0 stops the issue completely.

I'm running GNOME 3.20 on Wayland; haven't tried X11.

i915_edp_psr_status: (with enable_psr=-1)
Sink_Support: yes
Source_OK: yes
Enabled: yes
Active: yes
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: yes
Performance_Counter: 2397286

PCI ids:
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller])
	Subsystem: Lenovo ThinkPad T440p [17aa:220e]

I haven't yet tried getting the drm debug logs or running the intel-gpu-tools psr test case; I'll do that later today and attach the results here.
Comment 1 Calvin Walton 2016-04-27 19:36:59 UTC
Created attachment 123311 [details]
kernel-drm-debug-log

Here's a log with drm.debug=0xe

During this log, i set drm.debug to 0xe, then set i915.enable_psr to -1 (was 0). I then use the screen locker in GNOME to blank the screen; this causes the display to turn off, and when I turn the display back on psr is enabled (I checked i915_edp_psr_status before and after to verify this). The display then blinks several times, while the log prints repeated lines like

[20345.092329] sasami kernel: [drm:drm_mode_addfb2] [FB:59]
[20345.203191] sasami kernel: [drm:drm_mode_addfb2] [FB:61]

From watching the log live, I believe the blinks occurred between the line that said '59' and the line that said '61', but it's hard to tell due to possible buffering in systemd-journald.

Afterwards, I reset i915.enable_psr to 0 and set drm.debug back to 0.

If you want a complete log from boot with drm.debug enabled, let me know.
Comment 2 Jani Nikula 2016-04-28 08:01:13 UTC
(In reply to Calvin Walton from comment #1)
> If you want a complete log from boot with drm.debug enabled, let me know.

Yes, please.
Comment 3 Calvin Walton 2016-04-28 13:48:47 UTC
Created attachment 123324 [details]
kernel-drm-debug-log-full-boot

Here's the full boot log with drm.debug=0xe set and enable_psr unset (using default).

I boot the system, it starts gdm (wayland), I log in to gnome (wayland), then I wait for the display to blink several times.
Comment 4 dnord 2016-05-02 06:43:19 UTC
I'm having exactly the same issue on the same hardware (Thinkpad T440p) using X11.
Comment 5 Jani Nikula 2016-05-04 10:09:03 UTC
Possible dupe bug 95124.
Comment 6 dnord 2016-05-04 18:59:48 UTC
This can be related to the second bug https://bugs.freedesktop.org/show_bug.cgi?id=94985 with external monitor, which is also triggered by PSR and have explicit "fifo_underrun" error messages.
Comment 7 Rodrigo Vivi 2016-05-04 22:53:01 UTC
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?
Comment 8 dnord 2016-05-05 01:47:48 UTC
>So, regarding the occasional flicker, could you please check
i915.enable_psr=2 and also another boot with i915.enable_psr=3?
Occasional flickering of remains under all PSR settings, but looks like happens more often under enable_psr=2.
Comment 9 dnord 2016-05-05 02:57:16 UTC
>does anything special triggers the flickering?
Flickering starts immediately after booting.
First flickering occurs in the same moment, when lightdm is showing up, but I think it is another bug: https://bugs.freedesktop.org/show_bug.cgi?id=95214
I just noticed following regularities (I did these tests with enable_psr=2 because flickering occurs more often with this setting and it was easier to check guesses under it):
1. During complete idling (just watching desktop with no intensive applications running in the background) flickering does not occurs for me.
2. Stable and reproducible way to see flickering for me is to run htop (in the background or not). I did following observations during running htop.
3. When glxgears runs in the background no flickering occurs.
4. During playing video (maybe in background, but necessarily unminimized) no flickering occurs.
5. Just doing CPU demanding task as calculating md5 of large files is not enough to stop flickering.
Comment 10 Calvin Walton 2016-05-05 03:12:10 UTC
I convinced my friend with a ThinkPad X250 (Broadwell processor) to try out a 4.6-rc kernel, and he's seeing the same issue - screen occasionally flickering black - as well. I didn't have a chance to pull any debug logs on that machine.

My experience is basically the same as dnord - the screen flickering happens most often when the screen is being intermittently updated. It never happens if there's a continuous animation like a spinner or a video playing. It seems like it's most likely to happen shortly after something stops moving/changing onscreen - perhaps it's flickering when psr is activating?

I confirmed earlier that it happened with both the enable_psr=2 and enable_psr=3 modes (I tried both with a clean boot), but I had to wait longer to see a flicker happen when using the '3' mode.
Comment 11 Dmitry Nezhevenko 2016-05-17 14:33:54 UTC
Same issue on my t440p with X11
Comment 12 Cristian Magherusan-Stanciu 2016-05-18 11:19:17 UTC
I have the same issue on the released 4.6.0, on a Dell latitude e7240.

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)

Here's how it looks like (see around 0:26):

https://goo.gl/photos/WQjk9nerdDiy5ckJ7

I noticed it happens on a regular basis, about once every 90-95 seconds.
Comment 13 Dennis Brünig 2016-05-21 16:17:09 UTC
Kernel 4.6.0 on device 
XPS 13 9343

/proc/cmdline:
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=... nmi_watchdog=0 net.ifnames=0 i915.enable_fbc=1 i915.enable_rc6=7 i915.enable_psr=1

Weither enable_psr is set to 1, 2 or 3 there is still flicker occasionally. How can I help to pinpoint the bug?
Comment 14 Peter Frühberger 2016-05-22 18:58:40 UTC
Created attachment 123968 [details] [review]
Patch by danvet to fix the issue

My Thinkpad T440s also was affected. The attached patch fixes the issue.
Comment 15 Calvin Walton 2016-05-22 19:13:56 UTC
I'd like to leave it a while longer to make sure, but it looks like Daniel Vetter's patch has fixed this issue on my T440p as well.

I see it's got a CC:stable, so hopefully it'll make it into the 4.6.1 stable release…
Comment 16 dnord 2016-05-22 21:13:35 UTC
I'm no longer having this problem with inter-drm-nightly kernel and i915.enable_psr=1 (as it includes mentioned patch "drm/i915/psr: Try to program link training times correctly"). However I'm still having frequent flickering with i915.enable_psr=2. The problem is I actually need to use i915.enable_psr=2, because it is workaround for another bug, which happening with i915.enable_psr=1 but not with i915.enable_psr=2: https://bugs.freedesktop.org/show_bug.cgi?id=94985
Comment 17 Michael Groh 2016-05-23 07:40:27 UTC
Hello everyone,

on my Lenovo Thinkpad X250 (i5-5200U, Broadwell-U, HD 5500), i was affected by the flickering, just as the Bug describes. This has been fixed with the patch by danvet in attachment 123968 [details] [review].

I do hope that this patch gets included in 4.6.1.

Thank you for your work, have a nice day,
Michael
Comment 18 dnord 2016-05-23 11:01:23 UTC
Oh, no. Jubilation was premature! Screen is still flickering on Thinkpad T440p, but very-very rarely (like once in a hour or ten minutes) with i915.enable_psr=1. And rather frequently with i915.enable_psr=2, which indicates that problem was not eradicated completely. I'm currently testing with second VGA monitor attached, if it matters.
Comment 19 Dhinakaran Pandiyan 2016-05-23 18:28:35 UTC
@dnord, i915.enable_psr=2 is not expected to work for HSW/BDW at this point. We still have to figure out why your VGA monitor flickers with i915.enable_psr=1. It does seem like a different issue.
Comment 20 dnord 2016-05-25 17:50:44 UTC
>Screen is still flickering on Thinkpad T440p, but very-very rarely
Disregard that, I think it is another problem introduced by unstable changes in intel-drm-nightly build I use, blinking is now happens non-regularly and prints stack traces about drm_atomic when occurs.
Comment 21 soren121 2016-05-29 03:05:42 UTC
I can confirm that danvet's patch fixes PSR on my Broadwell laptop (Dell XPS 13 [9343], i5-5200U, HD 5500 Graphics). 

With an unpatched 4.6.0 kernel, the built-in display would flicker every few minutes, sometimes more often. With danvet's patch, it hasn't flickered once. 

I don't use an external monitor so I can't speak to those issues.
Comment 22 Dennis Brünig 2016-05-29 19:43:20 UTC
dell xps 13 9343, kernel 4.6 patched, enable_psr=1, no flicker.

I noticed a glitch that happens after the display switched off by DPMS (display power management signaling). The device was not suspended (s1) and is still on (s0). After the display is awaken by pressing a key/touching touchpad the old content of the frame buffer is used until the device is put into S1 after that it behaves normally again. Until then the display only updates its contents once after each tap on the touchpad. This glitch does not happen with enable_psr=0.
Comment 23 Jason Mamoa 2016-06-03 12:28:33 UTC
It still flickers incidentally on my Broadwell-U, HD 5500 with kernel 4.6.1 and https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=03b7b5f983091bca17e9c163832fcde56971d7d1 patch although more rarely like with enable_psr=3 before (or maybe even less but still)
Comment 24 Jason Mamoa 2016-06-03 12:37:37 UTC
Additional info: Kde, kwin_x11, modesetting driver
cat /sys/kernel/debug/dri/0/i915_edp_psr_status
ink_Support: yes
Source_OK: yes
Enabled: yes
Active: yes
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: yes
Performance_Counter: 1603397

The flickering appears random, sometimes there are none in a long period of time, sometimes twice in a couple of seconds.
Comment 25 dnord 2016-06-03 12:48:34 UTC
Jason Mamoa: Аre you getting additional error messages in dmesg? I had irregular flickering with some of intel-drm-nightly kernels, which had patch included, but it was a new issue. Check if it is still psr-related.
Comment 26 Jason Mamoa 2016-06-03 15:50:27 UTC
As described above I'm using stable kernel 4.6.1 + patch, not drm-nightly. After disabling psr flickering is gone.

I noticed following lines in dmesg which I think correlates with flickers:

[drm:intel_dp_set_drrs_state] eDP Refresh Rate set to : 40Hz
[drm:intel_dp_set_drrs_state] eDP Refresh Rate set to : 60Hz
Comment 27 Mihai Dontu 2016-06-03 23:22:08 UTC
I was having the same flicker issue with 4.6.0 on i7-4600U (Haswell). Now I'm running 4.7-rc1 and have not noticed it anymore.

# cat /sys/kernel/debug/dri/0/i915_edp_psr_status 
Sink_Support: yes
Source_OK: yes
Enabled: yes
Active: no
Busy frontbuffer bits: 0x000
Re-enable work scheduled: yes
Main link in standby mode: no
HW Enabled & Active bit: no
Performance_Counter: 15336055
Comment 28 Jason Mamoa 2016-06-04 15:49:25 UTC
Yes, 4.7-rc1 kernel apparently fixes it indeed. So it's something more than just one patch then.
Comment 29 Michael Groh 2016-06-15 08:42:56 UTC
For me, 4.6.2 fixed this issue on the Thinkpad x250 i am using. If someone can confirm that this is also fixed with 4.6.2, we can close this bug :)
Comment 30 AnAkkk 2016-06-15 08:44:19 UTC
I am on 4.6.2 and I still have this issue. I have to boot with enable_psr=0 otherwise my screen turn off and on every few seconds.

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
Comment 31 Calvin Walton 2016-06-15 15:12:38 UTC
To follow up with my experiences:

I've tried Daniel Vetter's patch as attached to this issue, both standalone on top of 4.6.1 and as it was merged into 4.6.2.

This patch, by itself, significantly reduces but does not eliminate the occasional black 'flicker'. At this point, the rate is reduced sufficiently that the system's actually usable - I maybe see one or two flickers over about half an hour of typical usage, rather than several per minute. Using i915.enable_psr=0 still makes them go away completely.
Comment 32 Dhinakaran Pandiyan 2016-06-15 19:34:57 UTC
Thanks for updating the results. Can you try these patches that are not present in 4.6.2- https://patchwork.freedesktop.org/series/8046/ ?
Comment 33 Dmitry Nezhevenko 2016-06-16 16:09:12 UTC
It looks like 4.6.2 + https://patchwork.freedesktop.org/series/8046/ works for me.

I don't see any flickering at all. Will confirm after a few days of testing.
Comment 34 Dhinakaran Pandiyan 2016-06-16 18:35:47 UTC
Great! Can you also run "watch -n 0.1 cat /sys/kernel/debug/dri/0/i915_edp_psr_status" on a second display or ssh? I am curious if PSR is getting activated with these patches.
Comment 35 Dhinakaran Pandiyan 2016-06-16 18:36:34 UTC
*** Bug 96277 has been marked as a duplicate of this bug. ***
Comment 36 Dmitry Nezhevenko 2016-06-16 19:02:06 UTC
It looks like something very strange happens. I'm not sure whether it's caused by patches or it's just mainline 4.6.2 behavior. 

I've docked my t440p laptop to dock with external monitor connected and configured internal eDP as secondary.

And got followed: https://youtu.be/kfiqEOpQ1do

So I'm getting flickering on external monitor. But when I'm displaying watch -n 0.1 cat /sys/kernel/debug/dri/0/i915_edp_psr_status everything seems to be ok.

Also when I'm typing something flickering stops for a while.

dmesg contains followed:
[23279.278108] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[23279.278119] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[23393.451412] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[23393.451422] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
Comment 37 Calvin Walton 2016-06-16 19:09:25 UTC
I've confirmed (with watch cat /sys/kernel/debug/dri/0/i915_edp_psr_status) that PSR is still being activated on my T440p with https://patchwork.freedesktop.org/series/8046/ applied.

I'd like to give it another day or so of testing to make sure, but it seems like the flicker on the internal screen is gone.

I'm presently using this system docked ("Ultra" dock with internal DP hub) with multiple external DP & HDMI monitors, and the internal screen disabled, and I'm not seeing any issues on the external screens like Dmitry has. I'll give it a try with the internal display enabled to see if I hit the same thing. I would imagine the corrupted display on external monitor is probably unrelated to this eDP PSR issue, though.
Comment 38 Dmitry Nezhevenko 2016-06-16 19:10:37 UTC
With internal screen disabled everything seems to be OK with docked monitors (both with or without patches).
Comment 39 Calvin Walton 2016-06-16 19:28:12 UTC
When I re-enable the internal display on my T440p I have the following display configuration:

- eDP internal display (1920x1080)
- Thinkpad Ultra dock
 |- DP monitor (2560x1440)
 \- HDMI monitor (1920x1080)

Immediately after enabling this configuration, the kernel log printed:
[17481.417387] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe B
[17481.417392] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B FIFO underrun

(I don't presently have any debug logging enabled, will retest with that later)

and the external DP monitor started blanking out for longish periods of time, up to several seconds (moving the mouse would usually cause the picture to re-appear.

The external HDMI monitor didn't blank completely, but did appear to lose sync or display corrupted picture - e.g. horizontal offset, shaking picture.

Disabling psr (with the option i915.enable_psr=0 option) fixes this completely.
Comment 40 dnord 2016-06-17 04:00:53 UTC
Blinking of external monitor due to psr looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=94985. Check if it is gone with enable_psr=2 as in that bug.
Comment 42 Calvin Walton 2016-06-17 14:31:41 UTC
Mika's patch at https://patchwork.freedesktop.org/patch/93927/ doesn't appear to apply on top of 4.6.2 with or without the series https://patchwork.freedesktop.org/series/8046/ applied; is there a different base kernel or branch I should be using?
Comment 43 Jani Nikula 2016-06-17 14:48:16 UTC
Just try reverting these, it's the same thing:

5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP link training optimization")
Comment 44 ExecutorElassus 2016-07-01 17:09:15 UTC
I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving (in which case the screen is steady). If I set i915.enable_psr=0 in the kernel options at boot, the screen does not flicker, but it also does not update *at all* unless I move the mouse. That is:

1) type some commands and hit enter → nothing changes on screen
2) move the mouse → the screen updates, showing that the commands have run and showing output.

Both of these states (ie, flickers, or no flicker but also no refresh, unless the mouse is moving) render my laptop more or less unusable. What are the other possible ways to fix this? Does danvert's patch resolve the issue?
Comment 45 Dennis Brünig 2016-07-02 10:12:16 UTC
(In reply to ExecutorElassus from comment #44)
> I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo
> 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving
> (in which case the screen is steady). If I set i915.enable_psr=0 in the
> kernel options at boot, the screen does not flicker, but it also does not
> update *at all* unless I move the mouse. That is:
> 
> 1) type some commands and hit enter → nothing changes on screen
> 2) move the mouse → the screen updates, showing that the commands have run
> and showing output.
> 
> Both of these states (ie, flickers, or no flicker but also no refresh,
> unless the mouse is moving) render my laptop more or less unusable. What are
> the other possible ways to fix this? Does danvert's patch resolve the issue?

dell xps 13 2015. Arch Linux, latest X11 server with xf86-video-intel, default options except dri3.

When enable_psr=1 is set: Similar problem as Executor has with screen not refreshing unless mouse moved BUT this is only happening AFTER first/second return from dpms screen blanking. 

In this state the device might also freeze when trying to manually activate suspend to ram (automatic suspend to ram works when timeout reached). 

This state returns to normal after resuming (returning from suspend to ram).

This state does not appear with enable_psr=0.
Comment 46 AnAkkk 2016-08-13 19:01:55 UTC
I just updated to 4.7 on Arch, and the issue is still present. The screen keeps flickering unless I set enable_psr to 0.
Comment 47 Dhinakaran Pandiyan 2016-08-19 00:38:53 UTC
(In reply to ExecutorElassus from comment #44)
> I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo
> 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving
> (in which case the screen is steady). If I set i915.enable_psr=0 in the
> kernel options at boot, the screen does not flicker, but it also does not
> update *at all* unless I move the mouse. That is:
> 
> 1) type some commands and hit enter → nothing changes on screen
> 2) move the mouse → the screen updates, showing that the commands have run
> and showing output.
> 
> Both of these states (ie, flickers, or no flicker but also no refresh,
> unless the mouse is moving) render my laptop more or less unusable. What are
> the other possible ways to fix this? Does danvert's patch resolve the issue?

Danvet's patch won't help if PSR is not enabled.

Can you do a `cat /sys/kernel/debug/dri/0/i915_edp_psr_status` to confirm PSR is not enabled?
Comment 48 Dhinakaran Pandiyan 2016-08-19 00:42:52 UTC
(In reply to AnAkkk from comment #46)
> I just updated to 4.7 on Arch, and the issue is still present. The screen
> keeps flickering unless I set enable_psr to 0.

Please post the output of `lspci  -vs 00:02.0` and full dmesg with drm.debug=0x14.
Comment 49 AnAkkk 2016-08-21 09:44:29 UTC
Output of lspci:

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 0781
	Flags: bus master, fast devsel, latency 0, IRQ 33
	Memory at d3000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 5000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915


I can email you the dmesg?
Comment 50 raoul 2016-08-23 15:19:37 UTC
On my i7-4510U with kernels 4.6 and 4.7 system always hangs after boot (as soon as gdm appears), and only i915.enable_psr=0 solves the problem. Kernel 4.5 worked flawlessly. This is my lscpi output:

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0005
	Flags: bus master, fast devsel, latency 0, IRQ 46
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915
Comment 51 raoul 2016-08-23 15:21:15 UTC
This is the missing Capabilities section in my previous comment:

	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
Comment 52 Erik Ekman 2016-08-29 19:29:57 UTC
I have a Toshiba Portege Z30A-15M with i7-4500U which hangs during boot a few seconds after the window to enter the root partition encryption key is shown.

4.5 works fine, and I found this change by bisecting. (03b7b5f983091bca1, drm/i915/psr: Try to program link training times correctly)

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Toshiba America Info Systems Device 0005
        Flags: bus master, fast devsel, latency 0, IRQ 44
        Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 3000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915

Using the enable_psr=0 argument makes my machine boot normally with later kernels.
Comment 53 Jani Nikula 2016-09-20 12:56:49 UTC
*** Bug 95124 has been marked as a duplicate of this bug. ***
Comment 54 Martijn van Dijk 2016-10-06 11:51:19 UTC
I am experiencing the same problems on a thinkpad e540p (similar hardware) on arch linux with kernel 4.7.6-1. I beleive this was introduced in kernel 4.6.x. Kernel 4.5.x works fine, later kernels require booting with i915.enable_psr=0 to resolve the issue.

I would love to provide more information if needed - I'm not exactly sure what information is relevant as this is the first time I'm getting involved in this sort of thing.
Comment 55 chrhei 2016-10-12 15:53:19 UTC
I am experiencing the same issues on my Lenovo Thinkdad L540 on Manjaro (Arch-Linux) with kernel 4.8.1-1-Manjaro. These problems were introduced in kernel 4.6.x, which require booting with i915.enable_psr=0 to resolve the issue.
Comment 56 yann 2016-12-14 08:18:40 UTC
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.
Comment 57 Paulo Zanoni 2016-12-14 20:39:15 UTC
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.
Comment 58 Steinar H. Gunderson 2016-12-15 08:21:26 UTC
FWIW, my X240 hasn't had PSR problems in a long time; it was fixed pretty early on in this bug. So it's not all doom and gloom :-)
Comment 59 Andreas Kloeckner 2016-12-15 08:32:06 UTC
Same here--no issue on X250 (Broadwell) with kernel 4.6.
Comment 60 Paulo Zanoni 2016-12-15 11:39:03 UTC
(In reply to Steinar H. Gunderson from comment #58)
> FWIW, my X240 hasn't had PSR problems in a long time; it was fixed pretty
> early on in this bug. So it's not all doom and gloom :-)

(In reply to Andreas Kloeckner from comment #59)
> Same here--no issue on X250 (Broadwell) with kernel 4.6.

Unfortunately it's known to cause bugs on at least some panels, so we'll keep it disabled by default until that's solved. Feel free to continue with the i915.enable_psr=1 parameter if you want. But if you plan on reporting further bugs, please make sure to always go back to the default parameters before reproducing the bugs and getting the log files.
Comment 61 Peter Hatina 2019-04-22 19:19:12 UTC
Dell XPS 13 9380 running 5.0.7. Still affected.
Comment 62 Jose Roberto de Souza 2019-04-22 20:58:50 UTC
Hi Peter

Could you open a new issue and add logs?
https://01.org/linuxgraphics/documentation/how-report-bugs
If possible, could add logs your current kernel and drm-tip? So we can backport fixes for the stable kernel.


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.