|Summary:||[ILK] black flashes and black screen with modesetting or wayland|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||CLOSED FIXED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||ILK||i915 features:||display/watermark|
Description groucho 2016-08-26 14:12:09 UTC
Created attachment 126053 [details] dmesg I have been faced with this issue since 4.4 (4.2 was fine, haven't tested 4.3). Newer Kernels have improved the situation but it still occurs in 4.8rc3. I am unable to reproduce it anymore with UXA or SNA or more than one display, but it is still there with modesetting and a single display. * Symptoms : - The bottom part of the screen becomes black (just below the mouse cursor) and comes back to normal the next frame. Sometimes there is also an horizontal translation of the bad frame (as if the screen was shaken). With dmesg -w, there is also an error message ONLY the first time the bug occurs : [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun - Rarely, the screen becomes entirely black and the system can hang. * When : It seems to be triggered by the state of the mouse cursor (when the cursor disappears). The black flash occurs half of the time. The entire black screen is rare. * How to replicate : Open a terminal in a Xorg session Put the mouse cursor over it Hold a key and move the mouse over the terminal (the goal is to make the mouse cursor appear and disappear quickly) * Hardware : Thinkpad X201 Intel Core i5 520M Ironlake Intel HD Graphics Built-in display OR external monitor on VGA * Software : Ubuntu 16.04 and 16.10beta (also tried Arch Linux) Kernel 4.8.0-040800rc3-generic Architecture x86_64 Intel driver in modesetting
Comment 2 groucho 2016-09-04 20:25:41 UTC
I have just tested Fedora 25 alpha2 and the bug is also affecting Wayland. Same symptoms and same dmesg errors [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
Comment 3 Wyatt 2016-11-15 03:00:50 UTC
This just happened to me on a fresh Debian Sid install, too. Same laptop - Thinkpad X201 i5 520M iron lake Linux 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) Intel integrated graphics I noticed this problem disappears when I make this xorg.conf: Section "Device" Identifier "Intel" Driver "intel" EndSection There was another bug report I found this in, but after rebooting I CANNOT find where it was. I've had it crash twice (goes to black screen with leftmost pixels randomly flipping to yellow for a few seconds, then just shuts off). Usually it just flickers.
Comment 4 Wyatt 2016-11-15 03:01:08 UTC
BTW, I'm not using wayland.
Comment 5 Jani Saarinen 2016-12-09 10:16:18 UTC
Hi, Is this bug still valid?
Comment 6 groucho 2016-12-09 16:40:35 UTC
Hello, I have just checked with kernel 4.9 rc8 in modesetting and the bug is still there.
Comment 7 groucho 2016-12-09 17:24:06 UTC
I have also checked wayland (plasma) with the same kernel 4.9 rc8 and the bug is still there.
Comment 8 groucho 2016-12-17 17:19:20 UTC
In case it might help, I have made a reverse bisect a few months back and here is the commit that fixed the issue for UXA and SNA. Since many distros seem to be moving to modesetting (and wayland), it would be great to have even just a workwaround. commit e2e407dc093f530b771ee8bf8fe1be41e3cea8b3 Author: Matt Roper <email address hidden> Date: Mon Feb 8 11:05:28 2016 -0800 drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2) Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different screen). That workaround was accidentally dropped as we started working toward atomic watermark updates. Since we still aren't quite there yet with two-stage updates, we need to resurrect the workaround and treat the cursor as always active. v2: Tweak cursor width calculations slightly to more closely match the logic we used before the atomic overhaul began. (Ville) Cc: <email address hidden> Cc: <email address hidden> Cc: <email address hidden> Reported-by: <email address hidden> Reported-by: <email address hidden> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93892 Fixes: 43d59eda1 ("drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)") Signed-off-by: Matt Roper <email address hidden> Link: http://patchwork.freedesktop.<email address hidden> (cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb) Signed-off-by: Jani Nikula <email address hidden> Link: http://patchwork.freedesktop.org<email address hidden> :040000 040000 545634aa608f59cd8959a6196761450afa57ee5b 7b3259c003cbd1e27e02c976d73af848f69d248c M drivers
Comment 9 groucho 2016-12-19 16:56:33 UTC
I have just tried drm-intel-nightly and modesetting, the bug is still there. The error message I get when the screen has its first flash is now : [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
Comment 10 groucho 2017-03-03 13:27:25 UTC
I can not reproduce the bug with the latest drm-intel-nightly with both modesetting and wayland. My test method feels a little choppier, but the screen doesn't flicker and there are no error messages in dmesg. Thank you very much. I hope it also fixed the occasional black screen crash.
Comment 11 yann 2017-03-03 13:30:54 UTC
(In reply to groucho from comment #10) > I can not reproduce the bug with the latest drm-intel-nightly with both > modesetting and wayland. > My test method feels a little choppier, but the screen doesn't flicker and > there are no error messages in dmesg. > > Thank you very much. > > I hope it also fixed the occasional black screen crash. Thanks Groucho for your confirmation. In case the occasional "black screen crash" is occurring again, please fill a new bug with corresponding logs.