Summary: | SKL screen flicker and dmesg [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun | ||
---|---|---|---|
Product: | DRI | Reporter: | Mihajlo Milenovic <mikipn.88> |
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Status: | RESOLVED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | high | CC: | baelish, grahamnorthup, imre.deak, ingvar, intel-gfx-bugs, lakshminarayana.vudum, mikipn.88, mirh, mmokrejs, nayef.ghattas, nicholas, russianneuromancer, sten.heinze, ville.syrjala, v.ondruch |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | KBL, SKL | i915 features: | display/watermark |
Bug Depends on: | |||
Bug Blocks: | 105980 | ||
Attachments: |
Description
Mihajlo Milenovic
2017-10-11 18:13:41 UTC
Hi Same issue here on HP EliteBook Folio G1 (m5-6Y54) with Linux 4.14 on Kubuntu 17.10. Error message in dmesg in the same. Unless i915.enable_rc6 is disabled, screen is flicker when power adapter is detached. Hello, Could you please attach full dmesg with debug information, drm.debug=0xe parameter on grub?? Thank you. Hi. I cant do that now, but I can tell I fixed the issue by removing iommu flag from kernel. Cant pas trough now with kvmgt.. but dont need it now. Will play with grub on weekend Created attachment 136368 [details] dmesg with debug Hello! > Could you please attach full dmesg with debug information, drm.debug=0xe parameter on grub?? Attached. btw, that was log from this kernel cod/tip/drm-tip/2017-12-21 (e17acd399942e58eacf1c7c619db88d7abd8a8f4) Could you try using dmc firmware for SKL https://01.org/linuxgraphics/downloads/firmware? I confirm this bug on kernel 4.13.0-1-amd64, using a "VGA compatible controller: Intel Corporation HD Graphics 515 (rev 07)", even with the latest Intel SKL microcode [ 2.430470] kernel: microcode: sig=0x406e3, pf=0x80, revision=0xba model : 78 model name : Intel(R) Core(TM) m5-6Y54 CPU @ 1.10GHz stepping : 3 microcode : 0xba I also confirm that i915.enable_rc6=0 is a workaround. 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. This bug has a dmesg 4.15.0-994 with drm.debug=0xe and report that i915.enable_rc6=0 is a workaround. can you test with latest drm-tip: https://cgit.freedesktop.org/drm-tip? I can confirm that the bug re-appears in 4.16 and exists in the latest (4.17rc3) drm-tip on a late 2017 razer blade stealth eDP (laptop display). I'm pretty sure this appears on LOTS of other laptops with hi-res (3200x1800) screens using hd620 hardware. Apparently, most have not updated to 4.16 where rc6_enable is disabled....yet. It's nearly unusable unless near seizure-inducing flicker is something you desire. Please let me know how I can help as I'd like this to be fixed. I've been using i915.enable_rc6=0 as a workaround for months. Since May 9, I'm running kernel 4.16 (Debian Testing) and my screen is flickering again. So i915.enable_rc6=0 is not a workaround anymore. Is there another workaround? (In reply to Martin Monperrus from comment #12) > I've been using i915.enable_rc6=0 as a workaround for months. > > Since May 9, I'm running kernel 4.16 (Debian Testing) and my screen is > flickering again. > > So i915.enable_rc6=0 is not a workaround anymore. > > Is there another workaround? Are BIOS updates available for the machine? For the record, the commit removing the option: "drm/i915: Remove unsafe i915.enable_rc6" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/i915_params.c?h=v4.16&id=fb6db0f5bf1d4d3a4af6242e287fa795221ec5b8 No ambiguity. Unfortunately, I cannot find a bios update for my HP EliteBook Folio G1. (In reply to russianneuromancer from comment #1) > Unless i915.enable_rc6 is disabled, screen is flicker when power adapter is > detached. We shouldn't have anything that's dependent on being on battery power. Points at BIOS like noted by Ville. (In reply to Martin Monperrus from comment #15) > Unfortunately, I cannot find a bios update for my HP EliteBook Folio G1. Ehrm.. There has been one like 3 weeks ago? https://support.hp.com/us-en/drivers/selfservice/hp-elitebook-folio-g1-notebook-pc/9764622 Some mishaps "when on battery power" are also indeed mentioned (for as much as possibly still unrelated to this problem) *** Bug 106467 has been marked as a duplicate of this bug. *** I can confirm that I still have the screen flickering on the latest kernels on my Razer Blade Stealth with intel hd620. Issues with screen flickering: - Running Arch linux with the latest kernel (4.17.5-1, 4.17.8-1 tested) - Running Arch linux with lts kernel and without kernel tag `rc6_enable=0` (4.14.54-1-lts, 4.14.56-1-lts tested) No issues with screen flickering: - Running Arch linux with lts kernel with kernel tag `rc6_enable=0` (4.14.54-1-lts, 4.14.56-1-lts tested) - Running Arch linux with any kernel tested whilst plugged in to vcore2 (egpu box) both with and without gpu installed. Note, though plugging into the vcore2 egpu box appears to alleviate the issue, plugging in a normal power adapter does not. Please let me know if I can help with troubleshooting. An additional workaround which works with the newer kernels: Add `intel_idle.max_cstate=4` kernel option works with 4.17.8-1 kernel. I confirm that kernel option "intel_idle.max_cstate=4" works for me on 4.17.0. Thanks a lot Harold! Reporter, do you still have the issue? If so can you check the issue with latest drm-tip https://cgit.freedesktop.org/drm-tip . Still exists can you attach the dmesg log booting with drm.debug=0xe. If not, this defect can be closed. Created attachment 141559 [details]
dmesg with debug - latest tip
I have this bug on my laptop. I'm on ArchLinux so I took the liberty to install linux-drm-tip-git, and I still find the same issue with the latest drm kernel. I attached the dmesg log with debug.
Hi, Is there an update on this issue ? As said previously, this makes the screen near unusable on the Razer Blade Stealth HD620 without setting intel_idle.max_cstate=4 as the enable_rc6 flag was removed on latest kernels. Thanks ! This issue is still reproducible on HP EliteBook Folio G1 I mentioned in Comment 1 on today drm-tip. Now flickering is much, much worse. Is anyone from Intel could look into this after all? Here's another one not working. HP EliteBook Folio G1, Intel HD Graphics 515 rev 07, running fedora 28/x86_64. Problem on all kernels since around 4.16.12. Booting with intel_idle.max_cstate=4 hides the problem. Ingvar I filed bug 106467 which was duped here. In order to do a BIOS update I had to put Windows back on which wiped my Linux install. After the BIOS update and reinstalling everything was working fine. I attribute this to having updated the BIOS but I can't be absolutely certain. > In order to do a BIOS update I had to put Windows back on which wiped my Linux install. Nick, you don't need Windows for BIOS updates. You can simply extract BIN file with firmware from HP updater with 7z, and then update from BIOS itself. > After the BIOS update and reinstalling everything was working fine. For me issue is still reproducible with latest BIOS and latest kernel (both of stable and drm-tip).
> For me issue is still reproducible with latest BIOS and latest kernel (both
> of stable and drm-tip).
Can you attach the latest dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M?
Created attachment 142489 [details] dmesg with debug - latest tip dmesg with cod/tip/drm-tip/2018-11-16 (c9e35242429a47b1c550dce738933bbd1739d897) is attached. I also tried workaround from https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18 and found that it works for our case. Is anyone else can confirm that? *** Bug 108048 has been marked as a duplicate of this bug. *** (In reply to russianneuromancer from comment #30) > Created attachment 142489 [details] > dmesg with debug - latest tip > > dmesg with cod/tip/drm-tip/2018-11-16 > (c9e35242429a47b1c550dce738933bbd1739d897) is attached. > > I also tried workaround from > https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18 and found that it > works for our case. Is anyone else can confirm that? Imre, can you help here? Mihajlo, Do you still have the issue? If so, can you please reproduce this issue with drmtip? Feedback from drmtip is needed as there were few changes related to watermarks are done recently. Hello from kernel 5.1.3! I have different hardware from this poster, but the same symptoms--the noted line in dmesg, and screen flicker on the local output. The device is a Surface Pro 1 (notoriously good Linux support, I know); I have the output of lshw, lscpu, dmesg, my .config, etc. if anyone wants them to be in this report. This isn't a Fedora system, but I'm more than happy to let this be the test monkey for any fixes. So far, my workaround has been passing "nomodeset" and letting the kernel hang onto the efifb. Of course, without DRM/KMS, most graphical environments don't work. I've also tried the other two workaround parameters (i915.enable_dc=0 as an interpretation of one, and intel_idle.max_cstate=4 verbatim) to no avail. I'd love to try https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18, but I'm not sure which kernel configs to twiddle to make that show up. (In reply to Graham Northup from comment #34) > Hello from kernel 5.1.3! I have different hardware from this poster, but the > same symptoms--the noted line in dmesg, and screen flicker on the local > output. The device is a Surface Pro 1 (notoriously good Linux support, I > know); I have the output of lshw, lscpu, dmesg, my .config, etc. if anyone > wants them to be in this report. > > This isn't a Fedora system, but I'm more than happy to let this be the test > monkey for any fixes. > > So far, my workaround has been passing "nomodeset" and letting the kernel > hang onto the efifb. Of course, without DRM/KMS, most graphical environments > don't work. > > I've also tried the other two workaround parameters (i915.enable_dc=0 as an > interpretation of one, and intel_idle.max_cstate=4 verbatim) to no avail. > I'd love to try https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18, but > I'm not sure which kernel configs to twiddle to make that show up. Can you please attach the dmesg from boot with drmtip? (In reply to Lakshmi from comment #35) > (In reply to Graham Northup from comment #34) > > Hello from kernel 5.1.3! I have different hardware from this poster, but the > > same symptoms--the noted line in dmesg, and screen flicker on the local > > output. The device is a Surface Pro 1 (notoriously good Linux support, I > > know); I have the output of lshw, lscpu, dmesg, my .config, etc. if anyone > > wants them to be in this report. > > > > This isn't a Fedora system, but I'm more than happy to let this be the test > > monkey for any fixes. > > > > So far, my workaround has been passing "nomodeset" and letting the kernel > > hang onto the efifb. Of course, without DRM/KMS, most graphical environments > > don't work. > > > > I've also tried the other two workaround parameters (i915.enable_dc=0 as an > > interpretation of one, and intel_idle.max_cstate=4 verbatim) to no avail. > > I'd love to try https://bugs.freedesktop.org/show_bug.cgi?id=108462#c18, but > > I'm not sure which kernel configs to twiddle to make that show up. > > Can you please attach the dmesg from boot with drmtip? Latest drmtip can be found here (https://cgit.freedesktop.org/drm-tip). Created attachment 144335 [details]
arvarnelios 20190523 dmesg on drm-tip
Created attachment 144336 [details]
arvarnelios 20190523 .config for drm-tip
> > Can you please attach the dmesg from boot with drmtip?
>
> Latest drmtip can be found here (https://cgit.freedesktop.org/drm-tip).
Let me know if you need any more information; the .config was olddefconfig'd from the host 5.1.3 kernel, which is itself defconfig plus some (so it's a bit chunky).
To confirm, uname -a said on this boot:
Linux arvarnelios 5.2.0-rc1-drmtip+ #2 SMP Thu May 23 15:54:35 EDT 2019 x86_64 GNU/Linux
...the drm-tip repo was on commit db92db5... .
(Sorry about the spam!)
(In reply to Graham Northup from comment #39) > > > Can you please attach the dmesg from boot with drmtip? > > > > Latest drmtip can be found here (https://cgit.freedesktop.org/drm-tip). > > Let me know if you need any more information; the .config was olddefconfig'd > from the host 5.1.3 kernel, which is itself defconfig plus some (so it's a > bit chunky). > > To confirm, uname -a said on this boot: > Linux arvarnelios 5.2.0-rc1-drmtip+ #2 SMP Thu May 23 15:54:35 EDT 2019 > x86_64 GNU/Linux > > ...the drm-tip repo was on commit db92db5... . > > (Sorry about the spam!) Hi, to me this looks a different bug than thye original bug report. From dmesg I can see like this 3.942231] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A [ 3.942342] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun This issue could be a duplicate of Bug 102614. @Ville, can you correct me if I am wrong. (In reply to Lakshmi from comment #40) > (In reply to Graham Northup from comment #39) > > > > Can you please attach the dmesg from boot with drmtip? > > > > > > Latest drmtip can be found here (https://cgit.freedesktop.org/drm-tip). > > > > Let me know if you need any more information; the .config was olddefconfig'd > > from the host 5.1.3 kernel, which is itself defconfig plus some (so it's a > > bit chunky). > > > > To confirm, uname -a said on this boot: > > Linux arvarnelios 5.2.0-rc1-drmtip+ #2 SMP Thu May 23 15:54:35 EDT 2019 > > x86_64 GNU/Linux > > > > ...the drm-tip repo was on commit db92db5... . > > > > (Sorry about the spam!) > > Hi, to me this looks a different bug than thye original bug report. > From dmesg I can see like this > 3.942231] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* > uncleared pch fifo underrun on pch transcoder A > [ 3.942342] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO > underrun > > This issue could be a duplicate of Bug 102614. > > @Ville, can you correct me if I am wrong. No idea. No drm.debug=0xe used so can't see anything particularly useful from the log. (In reply to Graham Northup from comment #37) > Created attachment 144335 [details] > arvarnelios 20190523 dmesg on drm-tip Can you please attach dmesg with kernel parameters drm.debug=0x1e log_buf_len=4M? Created attachment 144343 [details]
arvarnelios 20190524 dmesg on drm-tip with drm.debug=0x1e
You got it! Hope that helps :)
Regarding HP EliteBook Folio G1 - is there any chances of fixing this particular laptop until end of the year? Due to this bug this device left without power saving for at least one and half year. (In reply to Graham Northup from comment #43) > Created attachment 144343 [details] > arvarnelios 20190524 dmesg on drm-tip with drm.debug=0x1e > > You got it! Hope that helps :) @Ville, are these logs helpful? (In reply to Graham Northup from comment #43) > Created attachment 144343 [details] > arvarnelios 20190524 dmesg on drm-tip with drm.debug=0x1e > > You got it! Hope that helps :) Totally different hw. Nothing to do with this bug. (In reply to russianneuromancer from comment #44) > Regarding HP EliteBook Folio G1 - is there any chances of fixing this > particular laptop until end of the year? Due to this bug this device left > without power saving for at least one and half year. Have you tested a fresh drm-tip in recent times? (In reply to Ville Syrjala from comment #46) > > Totally different hw. Nothing to do with this bug. Should I open a separate one for my hardware, then? The end result is still a usability issue :) Created attachment 144380 [details]
dmesg output from Lenovo T470s with drm.debug=0x1e
@Mihajlo, Do you still have the issue with latest drmtip? Can you confirm? On my side, I can confirm flickering/error is gone with latest drm-tip. > Have you tested a fresh drm-tip in recent times?
Yes, no flicker after boot, but still flicker after wakeup from suspend (S3).
(In reply to russianneuromancer from comment #52) > > Have you tested a fresh drm-tip in recent times? > > Yes, no flicker after boot, but still flicker after wakeup from suspend (S3). Can you attach the dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M? (In reply to russianneuromancer from comment #52) > > Have you tested a fresh drm-tip in recent times? > > Yes, no flicker after boot, but still flicker after wakeup from suspend (S3). For this case, can you please attach the logs from drmtip? Created attachment 144632 [details] dmesg with debug - latest tip > For this case, can you please attach the logs from drmtip? Sure, log from cod/tip/drm-tip/2019-06-25 (2f140a8e189cec48853768f3f4208cbf670419fc) on HP EliteBook Folio G1 is attached. To reproduce flickering I suspend and wakeup laptop twice, opened YouTube in Firefox and press pause. After that screen started to flicker (end of the log). Interestingly, I used to have issues with "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun", i.e. flickering on my secondary screen. But with recent updates of my Fedora Rawhide, I started to observe flickering on my primary screen with "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun" (In reply to Vít Ondruch from comment #56) > Interestingly, I used to have issues with > "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO > underrun", i.e. flickering on my secondary screen. But with recent updates > of my Fedora Rawhide, I started to observe flickering on my primary screen > with "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A > FIFO underrun" Can you please elaborate the issue? What is the scenario here? How often it occurs? What's the platform? Can you please attach the dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M? Have you verified the issue with drmtip? If not I would recommend to verify the issue with drmtip (https://cgit.freedesktop.org/drm-tip). (In reply to Lakshmi from comment #57) > (In reply to Vít Ondruch from comment #56) > > Interestingly, I used to have issues with > > "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO > > underrun", i.e. flickering on my secondary screen. But with recent updates > > of my Fedora Rawhide, I started to observe flickering on my primary screen > > with "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A > > FIFO underrun" > > Can you please elaborate the issue? What is the scenario here? How often it > occurs? What's the platform? I am using Lenovo T470s. Using the laptop screen as my primary with secondary monitor attached to Lenovo ThinkPad Pro Dock via DVI. And this is the frequency: ~~~ -- Logs begin at Thu 2019-05-09 05:57:56 CEST, end at Thu 2019-06-27 09:24:46 CEST. -- -- Reboot -- -- Reboot -- May 15 14:31:34 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun May 20 12:21:41 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun May 20 16:31:22 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 21 16:29:13 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 27 06:23:54 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 27 06:30:01 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 27 09:49:25 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- -- Reboot -- May 27 15:17:37 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 28 12:55:40 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun -- Reboot -- May 29 09:55:21 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 29 14:20:12 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 30 06:22:55 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun May 30 06:59:23 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- May 30 07:45:25 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun May 30 07:45:25 localhost.localdomain kernel: [drm:intel_fbc_underrun_work_fn [i915]] Disabling FBC due to FIFO underrun. -- Reboot -- -- Reboot -- Jun 04 10:47:31 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 04 10:53:54 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 04 11:33:23 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 04 11:34:04 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 04 11:34:25 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- -- Reboot -- Jun 04 14:32:04 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 04 15:20:00 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 05 06:30:01 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 05 06:37:07 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 05 09:41:38 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 05 09:54:06 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- -- Reboot -- -- Reboot -- -- Reboot -- Jun 10 15:11:10 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Jun 11 06:43:57 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- Jun 12 13:50:02 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 12 14:35:26 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Jun 13 12:15:33 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Jun 17 16:26:55 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 18 08:41:07 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 19 13:38:09 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 20 13:05:43 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 20 14:43:57 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun -- Reboot -- -- Reboot -- Jun 20 14:54:06 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 24 16:42:45 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 25 09:56:07 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Jun 25 10:08:47 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 25 10:58:00 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 25 12:59:38 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Jun 26 14:06:14 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 27 06:48:11 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Jun 27 07:04:31 localhost.localdomain kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun ~~~ > Can you please attach the dmesg from boot with kernel parameters > drm.debug=0x1e log_buf_len=4M? I sent that in comment 49. > Have you verified the issue with drmtip? If not I would recommend to verify > the issue with drmtip (https://cgit.freedesktop.org/drm-tip). This is my libdrm version: $ rpm -q *drm* -a libdrm-2.4.98-1.fc31.x86_64 No feedback from the reporter from more than few months. Closing this bug as WORKSFORME. This bug report has been updated by many users having issues for different scenarios. Also, there are users saying it got fixed. So, I would like to close this issue and ask users to open a new issue instead of using this issue. Recently there were changes related to underruns that might fix some of the issues. So verify the issue with drm-tip. If the issue persists with drmtip, create a new issue and remember to attach the dmesg logs from boot. New bugreport: Bug 111201 |
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.