SKL screen flicker after suspend and dmesg "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun" on HP EliteBook Folio G1
Submitted by RussianNeuroMancer @RussianNeuroMancer
Assigned to Intel GFX Bugs mailing list
Link to original bug (#111201)
Description
Created attachment 144856
dmesg with drm.debug=0x1e log_buf=4M (drm-tip 2019-07-23)
Original bugreport: Bug 103229
Relevant bugreport: Bug 108462
As described in Comment 55 of original bugreport, issue is still reproducible on HP EliteBook Folio G1, but now happen only after suspend / resume cycle.
In attached log (dmesg with drm.debug=0x1e log_buf=4M on cod/tip/drm-tip/2019-07-23 ec297a234e92aa258bba523320898f408d0cf147) I suspend and resume laptop once, switched between windowed and fullscreen mode on YouTube in Firefox, launched mc and exited from mc few times, back to Firefox, switched to fullscreen YouTube again, got flickering.
Workarounds:
- Imre workaround from https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18
2 intel_idle.max_cstate=4
**Attachment 144856**, "dmesg with drm.debug=0x1e log_buf=4M (drm-tip 2019-07-23)":
dmesg
Activity
added Community feature: display/Other feature: power/suspend-resume platform: SKL priority::medium severity::major + 1 deleted label
Hi, I am using kernel 5.3.4 with those boot options (with no success - still happening):
intel_idle.max_cstate=4 i915.enable_psr=0
but still occasionally I get:
[15807.397665] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] ERROR CPU pipe B FIFO underrun
and my external attached display port monitor on the dock is going black (only the left one, the right one stays ok) and about 1-2 seconds l8r picture is there again.
Anything else I can provide or try to get rid of those flicker / black screen?@RussianNeuroMancersaid:Torsten, your bug is Bug 108462
@skarana1 with drm-tip 2020-02-20 fbfd614e946dc8ba097ea684179eee70fb6e53ed issue got worse. Now screen flicker not after suspend, but right on text boot log dmesg2 or boot splash screen dmesg3
Count from original bug report, this issue is two and half years old. Could you please ask developers to look into this issue before hardware get obsolete?
mentioned in issue #81 (closed)
@skarana1 as per previous comment "feature: power/suspend-resume" label can be removed now.
Same problem here. Described in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872760 Flickers after suspend or after an xrandr command or after powertop calibration.
Oh that looks bad, opened already 9 month ago! For me it is a severe issue as a laptop needs standby and to lose power save state is a killer for the battery. So please help!
Let me repeat, that (as for me) the flicker happens only after suspend. My feeling is, that this are different bugs, but maybe I am wrong.
Beside the above mentioned workaround (which has for laptops the drawback of to high power drain) I found another one. I found that on my Folio G1 (core-m5 6th gen, Skylake) the flicker disappears if I lower the resolution. Switching back to 1920x1080 - flicker again.
As predefined resolutions are either low or give black stripes I created a custom resolution of 1912x1080 (you wouldn't notice the difference) and all is great. No flicker and no power drain, just 8 pixel (in a column) lost. As long there is no real solution (and I start not believe in it any longer) this is a good workaround.
@RussianNeuroMancer : Does this work for you too? I am running 5.4.0-40-generic #44 (closed)-Ubuntu kernel.
Edited by arno@arno I am afraid this workaround is not applicable in Gnome Shell Wayland session.
Although I am far away from beeing an expert in Linux graphics - pretty sure you can use your own defined resolutions/frequencies in Wayland too. Linux is very flexible. As for me I can live better with this reduced resolution than with crippled power saving. You can try a predefined smaller resolution to - just to test the workaround. As I have same device - it should work.
@@RussianNeuroMancer: This is valid for the HP Folio G1. create /etc/X11/xorg.conf.d/10-monitor.conf with this content.
Section "Monitor" Identifier "eDP1" Modeline "1912x1080_60.00" 171.25 1912 2032 2232 2552 1080 1083 1093 1120 -hsync +vsync Option "PreferredMode" "1912x1080_60.00" EndSection Section "Screen" Identifier "Screen0" Monitor "eDP1" DefaultDepth 24 SubSection "Display" Modes "1912x1080_60.00" EndSubSection EndSection Section "Device" Identifier "Device0" EndSection@arno thank you for trying to help. However, Wayland compositors does not read xorg conf files, only X.Org Server do, and I don't use it on this device for a couple of years.
@RussianNeuroMancer : I would wish the driver would be fixed.
Edited by arno@RussianNeuroMancer, Is this issue reproducing?
Please update your latest updates.
Issue is still reproducible on today drm-tip (2020-12-22 5c75b762ad66debdc7dc7821680795209fe997c0)
If yes, provide the steps to reproduce it for further debugging.
As per comment now issue is reproducible right-a-way, even on boot splash screen, and then on the desktop. No special actions is required. Just in case, this issue is three years old now. Could you please ask developers to look into this issue before hardware get obsolete?
I also cannot reproduce the flickering, but I do get those lines on EVERY boot since I am using this laptop (for more than 3 years now):
i915 0000:00:02.0: [drm] *ERROR* fifo underrun on pipe A i915 0000:00:02.0: [drm] *ERROR* pch fifo underrun on pch transcoder AThere seems to be no effect, means: everything works as expected. In comparison to the original bug report the difference is that I almost never use hybernation/standby. I have regularly connected external displays though, either over VGA or over miniDP (using a miniDP to HDMI adapter), and they all work as expected too.
The attatched dmesg output file was filtered, Kernel version 5.10.9 on Gentoo Linux: dmesg_drm.xz
# dmesg | grep -e "drm" -e "i915" > dmesg_drmThis file is with an external VGA display connected and set as the only display (laptop lid closed immediately after power on), from bootup to the desktop only the external VGA display was used. (Additionally, LVDS was selected off in the KDE Plasma display settings, which always gets restored after login if the lid is be open.)
My hardware:
thinkpad_acpi: ThinkPad BIOS G2ETB7WW (2.77 ), EC G2HT36WW thinkpad_acpi: Lenovo ThinkPad X230, model 2325AZ8From /var/log/Xorg.0.log:
(--) PCI:*(0@0:2:0) 8086:0166:17aa:21fa rev 9, Mem @ 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x00006000/64, BIOS @ 0x????????/131072# lspci -nn -s 02.0 -vv 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 3rd Gen Core processor Graphics Controller [17aa:21fa] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 29 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 6000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915I'm wondering why I get the error message ("fifo underrun") without any effect...
Edited by Andreas ThalhammerThere are more people suffered: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872760.
I think in the report are quite a few information that should help identify the root cause.
Edited by arno@ysainan any news?
I see
i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrunabout once a day. The display flickers once, that's it. I first reported FIFO underruns on Dell XPS 9560 (which I am still using) about 4 years ago. I'm on Arch and I use latest kernel and latest mesa. This issue has been a constant companion for the last 4 years.I would be eager to help, even though on my system there isn't really an impact due to this bug. Everything works for me, but it may be related to the relatively low display resolution of only 1366x768. External displays, for analog VGA I used up to 1280x1024 and for DVI I had up to Full HD 1920x1080 (but not at the same time: either VGA or DVI), worked so far as well, with and without the internal display as mirror or extension, but mostly I only use one display.
I constantly get the FIFO underrun, means: on every boot-up with every kernel for the last ~4 years.
I know other users are affected more. I would love to help. But we need devs! Please!
It seems like Kernel 5.13 fixes the FIFO Underrun Reporting for me. The newly introduced CONFIG_DRM_I915_REQUEST_TIMEOUT=20000 looks like it does this job, it is part of the Default request/fence expiry + watchdog patch series. I have to check yet what happens if I disable the timeout, i.e. set it to 0. On the other hand, since there were quite a lot i915+drm related changes in 5.13, it could be something completely different, like this...
Edited by Andreas ThalhammerOk, let's hope the best that this solves flickering after suspend. Someone know how to test this with Ubuntu running from USB stick? Probably this is impossible because one has to change/update the kernel and this USB's are not created for this operation. (I am not experience how this could be done on Ubuntu Mate 20.04LTS and I can't risk to mess my system).
Well, I found this article: 2 Utilities To Install The Latest Kernel In Ubuntu Or Linux Mint (GUI and Command Line). One of the options mentioned is to use the Mainline Kernel PPA. I myself don't use Ubuntu, so I don't know how to add this repository, but this might help.
You're right, on a USB flash drive I wouldn't compile my own kernel as it writes quite a lot of files (> 10 GB).
Good luck!
@drjhe : you do have a rather modern CPU. Beside the error message, do you see flickering after entering suspend and wake up? As long as I don't enter standby all seems to be fine. But Laptop needs standby...
@andreas-thalhammer : Installed 5.13 via https://linuxhint.com/install-upgrade-linux-kernel-4-9-2-ubuntu-linux-mint/
Linux 5.13.0-051300-generic
And I get same message
[ 0.368779] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [CAP1] at bit offset/length 64/32 exceeds size of target Buffer (64 bits) (20210331/dsopcode-198) [ 0.368861] ACPI Error: Aborting method \_SB._OSC due to previous error (AE_AML_BUFFER_LIMIT) (20210331/psparse-529) [ 1.143752] RAS: Correctable Errors collector initialized. [ 2.880650] i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun [ 23.523718] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro. Quota mode: none. [ 24.271900] hp_wmi: query 0x4 returned error 0x5 [ 24.297728] hp_wmi: query 0xd returned error 0x5 [ 24.484457] hp_wmi: query 0x1b returned error 0x5 [ 97.675620] i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrunIts even worse than the old kernel. I get a lot of artefacts already while booting. It is very interesting that the same method decribed above (switching to 1912x1080) helps. Damned guys, with this info it should be fixable.... Something frequency depending.
You mentioned a paramter CONFIG_DRM_I915_REQUEST_TIMEOUT=20000
But even that doesn't help:
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.13.0-051300-generic root=UUID=92c467dc-e394-4f19-a6a2-e7cf918f0ffb ro quiet splash CONFIG_DRM_I915_REQUEST_TIMEOUT=20000 vt.handoff=7
Edited by arnoSorry no updates on this lately. Is this still seen on latest drm-tip. @stan any comments / hints from you?
@jani.saarinen You probably meant me here :) Will check it, seems like there are multiple issues with FIFO underruns here. Problem is that FIFO underrun can be a symptom of a multiple issues.
If anyone still has some problems here - can you please post again the issue description and latest dmesg with drm.debug=0x1e added in kernel command line. THe issue seems to be 2 year old and obviously consists of multiple different issues actually.
Edited by slisovsk
@RussianNeuroMancer, Do you still see this issue on latest drmtip.
I am running an HP Folio that is affected, right now: Linux 5.4.0-100-generic #113 (closed)-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
If there is a chance to get rid of it, just let me know (in detail how to install kernel) what to do for testing.
@arno , please try with latest drm-tip. Currently at 5.17.0-rc6. See again instructions at: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
@arno CONFIG_DRM_I915_REQUEST_TIMEOUT=20000 is a kernel .config setting, not a boot option, i.e. run:
# cd /usr/src/linux ; grep -i -e i915 .config CONFIG_DRM_I915=y CONFIG_DRM_I915_FORCE_PROBE="" CONFIG_DRM_I915_CAPTURE_ERROR=y CONFIG_DRM_I915_COMPRESS_ERROR=y CONFIG_DRM_I915_USERPTR=y # CONFIG_DRM_I915_GVT is not set # CONFIG_DRM_I915_PXP is not set # drm/i915 Debugging # CONFIG_DRM_I915_WERROR is not set # CONFIG_DRM_I915_DEBUG is not set # CONFIG_DRM_I915_DEBUG_MMIO is not set # CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set # CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set # CONFIG_DRM_I915_DEBUG_GUC is not set # CONFIG_DRM_I915_SELFTEST is not set # CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set # CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set # CONFIG_DRM_I915_DEBUG_RUNTIME_PM is not set # end of drm/i915 Debugging # drm/i915 Profile Guided Optimisation CONFIG_DRM_I915_REQUEST_TIMEOUT=20000 CONFIG_DRM_I915_FENCE_TIMEOUT=10000 CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250 CONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500 CONFIG_DRM_I915_PREEMPT_TIMEOUT=640 CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000 CONFIG_DRM_I915_STOP_TIMEOUT=100 CONFIG_DRM_I915_TIMESLICE_DURATION=1 # end of drm/i915 Profile Guided Optimisation CONFIG_SND_HDA_I915=yNaturally, that will only work if you compile your own kernel and it's available at /usr/src/linux. I am unaware of boot-time options for i915 other than brightness. From kernel-parameters.txt, e.g. like so:
# cd /usr/src/linux ; grep -i -e i915 Documentation/admin-guide/kernel-parameters.txt i915.invert_brightness=I will also try the latest drm-tip if I find the time, and add the mentioned debug options, but I am currently no longer affected by the mentioned "pipe A FIFO underrun" message and I was never affected by a real flicker issue (except for an intial flicker maybe when setting a mode, which is a non-issue really...)
Edited by Andreas Thalhammer@jani.saarinen I tried the latest drm-tip, 5.17.0-rc6, and everything works as expected on my system. I have dmesg flooded with log messages from i915 with
drm.debug=0x1e log_buf_len=1Mso there's not much to gain from it, but I will try again without debug and with debug, but with a much bigger log_buf. For now, on my system I don't see any issues.To make this clear once more: I never had issues. I only ever had the dmesg log line
*ERROR* CPU pipe A FIFO underrunand I was curious of the reason for this error message. Since kernel 5.13 I don't see this dmesg line no more, at least on my system.My system: Lenovo ThinkPad X230. Internal display, 1366x768, and external via miniDP to HDMI (digital), 1920x1080 (FullHD). See my above messages for more info, with the only change that I don't use the (analog VGA D-Sub DE-15) display with 1280x1024 any more...
@arno Sorry.. this has been going on for so long! Lately there had been updates to the WM logic especially the case where there is single DRAM channel! It should help solve the Fifo underruns because of the WM issues! The changes are in the latest kernel! Could you try upgrade the kernel and try! And please provide the log if this still happens! Thanks (drm.debug=0xe log_buf_len=4M)
@vgovind2 : Thanks I will test this. But I need a bit support from your side. Ahead, I have just my productive Linux (Mint/Cinnamon 20.3) - so I need some assistance to keep my system booting! I used https://01.org/linuxgraphics/documentation/build-guide-0, and stopped before "make module_install". So what are the steps to keep my system alive? I am a bit afraid of installing a kernel/modules bypassing Mints original installation process. My /boot partition looks like that:
drwxr-xr-x 5 root root 4096 Aug 11 19:50 ./ drwxr-xr-x 19 root root 4096 Aug 12 2021 ../ -rw-r--r-- 1 root root 237947 Jun 22 15:00 config-5.4.0-122-generic -rw-r--r-- 1 root root 237947 Aug 4 03:48 config-5.4.0-124-generic drwx------ 4 root root 1024 Jan 1 1970 efi/ drwxr-xr-x 4 root root 4096 Aug 11 19:50 grub/ lrwxrwxrwx 1 root root 28 Aug 10 18:25 initrd.img -> initrd.img-5.4.0-124-generic -rw-r--r-- 1 root root 88491459 Aug 7 12:33 initrd.img-5.4.0-122-generic -rw-r--r-- 1 root root 88493139 Aug 10 18:27 initrd.img-5.4.0-124-generic lrwxrwxrwx 1 root root 28 Aug 10 18:25 initrd.img.old -> initrd.img-5.4.0-122-generic drwx------ 2 root root 16384 Aug 12 2021 lost+found/ -rw------- 1 root root 4758694 Jun 22 15:00 System.map-5.4.0-122-generic -rw------- 1 root root 4758850 Aug 4 03:48 System.map-5.4.0-124-generic lrwxrwxrwx 1 root root 25 Aug 10 18:25 vmlinuz -> vmlinuz-5.4.0-124-generic -rw------- 1 root root 13660416 Jun 22 15:26 vmlinuz-5.4.0-122-generic -rw------- 1 root root 13660416 Aug 4 03:54 vmlinuz-5.4.0-124-generic lrwxrwxrwx 1 root root 25 Aug 10 18:25 vmlinuz.old -> vmlinuz-5.4.0-122-genericCompiling ends with error: make[1]: *** Keine Regel vorhanden, um das Ziel „debian/canonical-certs.pem“
Does uncommenting this in .config (CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem") has no negative sideeffects? At least other questions pop up with that.
So, what to do else if above issue is solved? Just exchanging the vmlinuz isn't enough.
Edited by arno@arno Well.. in this case, you don't need to get drm-tip and compile etc. You can get the latest kernel 5.19 release and install. The fix I mentioned above w.r.t wm changes are already in the release! Could you try that and get the log from boot (with commandline params drm.debug=0x1e log_buf_len=4M) Also pls list the behavior you are facing as well!
@vgovind2 : My Mint 20.3 goes up til 5.15. So I upgraded to Mint 21, but it also doesn't support the 5.19 via its own update. The only I can observe, the 5.15 flickers even more - even right after boot, not only after wake up from suspend. Thanks god the 1912x1080 trick with reduced resolution still works.
@arno when googled, found this one -> https://forums.linuxmint.com/viewtopic.php?p=2222099 Well I cannot vouch for the instructions there or I have not tried that! May be you can look at that and see if it helps for you?
Also not sure if you have the kernel log attached from boot. May be you can attach your log as well.
@arno I don't know how to get the most recent Linux kernel from kernel.org to Linux Mint, but I found this: How to Install Linux Kernel 5.17 on Linux Mint 20 LTS – using the Ubuntu Mainline Repo, even the most recent kernel (as of this writing 5.19.5) should be available. Installing them should be fairly easy, just download the *.deb kernel packages and install them using dpkg (as described in the above linked webpage at linuxcapable.com).
I also found How to Compile a Linux Kernel, which is very generic, and Build custom kernel on Debian / Ubuntu – which Mint is based on, so it should work there as well. The only thing I would add is (between step 8 "make install" and 9 "reboot") to re-run grub-mkconfig to get the newly installed kernel as one of the boot options for GRUB2 (assuming that Mint uses GRUB, as almost every other Linux distribution does nowadays): "sudo grub-mkconfig -o /boot/grub/grub.cfg" (assuming this is where GRUB2 is mounted/located/accessible in Linux Mint). This way you can still choose which kernel to boot (giving you a fallback, should the newly compiled kernel not work).
Keep in mind that doing this wrong can (will? might?) render your system unbootable. So before you start: a backup plan (what to do should this happen) is a great idea... (a bootable live media is sometimes/often, but not always, able to restore a working configuration, but you'd have to know exactly what you're supposed to be doing.)
Edited by Andreas Thalhammer
