After waking from sleep or suspend, the graphics glitches out. This results in the display shaking violently on the screen. When I checked my journal, I found this error message: Sep 07 18:24:32 harish-x250 kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun I don't know what else I can provide to help with this bug. I do have early KMS to load my intel_agp and i915 modules since I' running arch. I did this so that I don't get black screen when I resume from hibernation.
I forgot to mention I'm running kernel 4.12.10 and my cpu is Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz with HD 5500 integrated graphics.
I must mention that this is reproduceable by letting the computer timeout, causing screen to dim and blankout (some sort of power saving feature in gnome). After waking the computer the mentioned problem happens. This is somewhat fixeable by closing the lid, letting the laptop suspend. Waking from suspend then causes the graphics glitch to go away.
Hello Harish, Could you please attach dmesg with drm.debug=0xe log_bug_len=2M parameter on grub from boot to problem. Thank you.
Thanks Elizabeth. Just one more thing, this problem didn't seem to occur in LTS 4.9.47. Furthermore, using those parameter in grub results in dmesg giving lot of messages on drm intel i915 stuff. I don't know if I should provide all the messages or not. It's also difficult to identify which part of the messages relates to the error because I have to suspend my laptop after the problem occurs. Any suggestion?
(In reply to Harish from comment #4) > Thanks Elizabeth. Just one more thing, this problem didn't seem to occur in > LTS 4.9.47. Furthermore, using those parameter in grub results in dmesg > giving lot of messages on drm intel i915 stuff. I don't know if I should > provide all the messages or not. It's also difficult to identify which part > of the messages relates to the error because I have to suspend my laptop > after the problem occurs. Any suggestion? If the problem didn't occur on 4.9 and down could be a regression. The drm.dbug parameter allows to show extra information in the dmesg that could be helpful to track possible origin of the error. That's why is helpful to have the whole archive. You mention after wake glitch may go away, so you can get the dmesg after that?
I'll do my best to provide the dmesg logs. In the meanwhile I've switched back to LTS kernel since I have critical work to be done. Please don't close this bug report for a while, as I will get around to testing the 4.12 series kernel when I'm free. For extra information, I remember not having this bug in 4.11 kernel either as far as I can remember, if that helps (I could be wrong though).
Created attachment 134298 [details] dmesg log after thegraphics glitch Here is the dmesg log that I took after the graphics glitch happened. I hope you find it useful. Please let me know if you need anything else. Sorry for the delay and thank you for your patience!
Just to make your life easier, I believe the fun stuff starts to happen around line 7422!
Thanks for the update, could you also attach an screenshot or photo of the glitchy image??
I will try my best, but please note that this may be difficult as sometimes the glitch goes away after a few seconds and I can't take a picture in time. It may thus take a few days for me to get the chance to catch this bug with my camera! :) Furthermore, I've tried setting intel_iommu=off in my grub kernel parameter. This does not seem to make the glitch go away. For more information regarding this bug, please see https://bugs.archlinux.org/task/55562#comment161231 At least one other person apart from myself is facing the same bug.
I have found an old post from 2015 regarding this issue. https://bbs.archlinux.org/viewtopic.php?id=197427 youtube link: https://www.youtube.com/watch?v=RGMjcHhyK0M Please visit the youtube link in this post. The same thing is happening to my screen. This should give the exact idea about what is happening to my screen. However, note that my issue happens usually when the computer wakes up after screen goes blank after timeout to go to sleep. I have already uninstalled stuff like tlp to rule out power saving stuff affecting this bug. however note that the dmesg was taken with tlp enabled. It seems the commit that tries to fix this problem has already been included in the kernel since 2015. I believe this commit should help my problem if I'm using the latest 4.12.14 kernel, but its not so I'm not sure what to do. here is the commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.12.14&id=c9f038a1a5924352ab8e510e4a45ac57b08db391 here is the mailing list that talks about it: https://lists.freedesktop.org/archives/intel-gfx/2015-May/066692.html Another person suggests using i915.enable_ips=0 as a temporary fix, but says it is not recommended. It was also suggested to use uxa acceleration. However since I'm running wayland, I cannot use uxa acceleration since xf86-video-intel does not work on wayland. I have not tried any of these options yet. Any suggestions? Your input is highly valued!
i915.enable_psr=0 as a kernel parameter might help since it causes problems, according to arch wiki. 4.9.x kernel appears to turn it off by default, and it may be that some kernel version after that turned it back on as default again. I have currently added it as grub kernel parameter but I am yet to test this out and verify. The dmesg logs show: [17174.796524] [drm:intel_psr_enable [i915]] PSR not supported by this panel [17174.796565] [drm:intel_edp_drrs_enable [i915]] Panel doesn't support DRRS [17174.853221] [drm:intel_print_rc6_info [i915]] Enabling RC6 states: RC6 on just before the message. [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun So any of these could be culprits according to arch wiki https://wiki.archlinux.org/index.php/intel_graphics#Screen_flickering Any suggestions?
Sorry for spam, perhaps this bug is related to this bug? https://bugs.freedesktop.org/show_bug.cgi?id=101111 ... based on the log messages. Not sure though.
Hello Harish, Easiest way to test would be using i915.enable_psr=0 to check if flickering stop, the other way would be to try with drm-tip branch https://cgit.freedesktop.org/drm-tip since patch form bug 101111 is merged there already.
I think the problem could lie in the RC6 sleep mode. PSR is disabled by default in all latest kernels. So the patch in https://bugs.freedesktop.org/show_bug.cgi?id=101111 would not really help. Just out of curiosity, how would I use the drm-tip? Does this involve patching and rebuilding the kernel? If so, how do I patch the whole thing? Sorry for noob question. I am literally an average desktop user.
We need the dmesg from boot. Please add log_buf_len=4M or similar to get it all.
*** Bug 102906 has been marked as a duplicate of this bug. ***
(In reply to Elizabeth from comment #17) > *** Bug 102906 has been marked as a duplicate of this bug. *** Please check attached logs and video in comment https://bugs.freedesktop.org/show_bug.cgi?id=102906#c3 Thanks.
I can confirm that disabling rc6 power saving by passing as kernel paramter gets rid of the problem. However, battery life is suffering. Perhaps it is not stable with my configuration Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz with HD 5500 integrated graphics.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
I've been running 4.15.* Arch stable kernels without "i915.enable_rc6=0" for a couple of last weeks and the bug does not appear anymore on my ThinkPad X250 (i5-5200U CPU). I did have the bug in 4.12 and 4.13 (not sure about 4.14, lived through it with "i915.enable_rc6=0").
based on feedback, closing, please re-open if still occurs.
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.