Created attachment 139258 [details] dmesg Steps to reproduce the issue. Boot kernel and desktop environment How often does the steps listed above trigger the issue? always -- system architecture: ("uname -m") drm-tip -- kernel version: ("uname -r"). drm-tip hash 844dd95837ab995c37d1139d74ff55139987b437 -- Linux distribution: Fedora -- Machine or mother board model: Gigabyte Technology Co., Ltd. B250M-D3H -- Display connector: (such as HDMI, DP, eDP, ...) DP A full dmesg with debug information and/or a GPU crash dump attached
screen flickers once when error appears in dmesg does not reoccur when FBC is disabled
[ 33.654881] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun [ 33.654928] [drm:intel_fbc_underrun_work_fn] Disabling FBC due to FIFO underrun. Is this duplicate of 105604? Paulo, can you have a look FBC one warning.
The bug is not in FBC. The bug is that we have a FIFO underrun. FBC plays on the safe side and disables itself in case we have a FIFO underrun. We should fix the FIFO underrun. I've seen FIFO underruns everywhere, including in CI, so this is a known problem.
(In reply to Paulo Zanoni from comment #3) > The bug is not in FBC. The bug is that we have a FIFO underrun. FBC plays on > the safe side and disables itself in case we have a FIFO underrun. > > We should fix the FIFO underrun. I've seen FIFO underruns everywhere, > including in CI, so this is a known problem. The fact that the flickering stops after FBC has been disabled may implicate FBC. Do we have an option to force FBC to stay on despite underruns? That could help in figuring out whether FBC is just the victim or the purpetrator.
(In reply to Ville Syrjala from comment #4) > (In reply to Paulo Zanoni from comment #3) > > The bug is not in FBC. The bug is that we have a FIFO underrun. FBC plays on > > the safe side and disables itself in case we have a FIFO underrun. > > > > We should fix the FIFO underrun. I've seen FIFO underruns everywhere, > > including in CI, so this is a known problem. > > The fact that the flickering stops after FBC has been disabled may implicate > FBC. Do we have an option to force FBC to stay on despite underruns? No, although that would be simple to implement. > That > could help in figuring out whether FBC is just the victim or the purpetrator. FBC just amplifies the problem, that's why disabling it improves the situation. That's by design. The only way FBC could be the culprit would be in case the FIFO underrun simply does not happen anymore when FBC is disabled. Bug reporter would need to boot with i915.enable_fbc=0 to verify that.
when booting with i915.enable_fbc=0 flickering and error does not occur
although it would be preferrable to trace the bug, which existed for a couple of years in different kernel versions, rather than doing a workaround
(In reply to vasily.pupkin from comment #6) > when booting with i915.enable_fbc=0 flickering and error does not occur Yes, but we need to check dmesg to see if the FIFO underrun error messages still happen. FBC just makes the bug (more) visible.
Accidentally hit submit, sorry. Can you please retest with i915.enable_fbc=0, then check dmesg to see if the FIFO underrun error messages still happen? Thanks, Paulo
And add dmesg also here.
Created attachment 139451 [details] dmesg with i915.enable_fbc=0
Attached dmesg with i915.enable_fbc=0, let me know if more info neded
Hello, are there any plans to fix this error?
Reporter, do you still have the issue? Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Paulo, how to proceed further? testing with latest drm-tip will help the situation?
Vasily, need dmesg from latest drm-tip for investigation. No feedback for more than a month, reducing the priority to medium.
No feedback for more than few months, closing this issue as WORKSFORME. If this issue happens to occur on drmtip, please attach the dmesg from boot and reopen the issue.
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.