Summary: | Screen Flickering on Intel Card | ||
---|---|---|---|
Product: | DRI | Reporter: | Carlo Abelli <carlo> |
Component: | DRM/Intel | Assignee: | Carlo Abelli <carlo> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | adl, dvlohp, freedesktop-bugs, intel-gfx-bugs, joakim.tjernlund, przanoni |
Version: | XOrg git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | SKL | i915 features: | display/watermark |
Description
Carlo Abelli
2016-04-18 23:32:30 UTC
I can confirm that this bug persists in kernel version 4.5.1 as well. Confirming that this affects multiple users: I also have a Dell XPS 13 (9350 model with Skylake). I previously upgraded to a 4.5 kernel from the arch linux testing repo and noticed the same flickering mentioned by Carlo. I then downgraded back to 4.4.5 and the flickering went away. Now that 4.5 is out of testing, I pulled it down in my latest update, and the flickering has returned. I do see the same message that Carlo mentions in dmesg output. It is the very last message in my output (see below with a little more context). It seems to be pretty consistent around that time at bootup regardless of how long I wait to login (but I have no idea if it's relevant - just confirming that I also see the message). [ 3.393442] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready [ 3.433790] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready [ 3.557638] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready [ 13.702477] IPv6: ADDRCONF(NETDEV_CHANGE): wlp58s0: link becomes ready [ 22.293947] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Lastly, booting with the "i915.enable_rc6=0" option does make the flickering stop. I'm on a MacBook Pro (13-inch, Early 2011, MC724LL/A). I'm on ArchLinux, kernel version 4.5.1-1, when I connect my laptop to the TV through a displayPort-to-HDMI cable the TV screen keeps blinking black on and off. I've then, as suggested, downgraded, problem is that the current LTS kernel for Arch is 4.4.8-1. I've downgraded to this version and still problem persisted and got even worse because after unplugging the cable, my laptop screen started to flicker when moving the mouse. I've then downgraded the linux-lts package using the AUR "downgrader" to version 4.1.21-1, the last one available before going after 4.4.5. At last now, everything is working as expected. Also, by the way, I was getting the same error messages and have also enabled the referred boot flag. It helped that my laptop monitor stopped flickering after unplugging the secondary one, but I still got the error messages when connecting it. And the flag didn't help stop the blinking on the second screen. I've used the downgrader from Arch to binary search the last kernel available that didn't provide the bad behavior, I'm now on 4.2.5-1, the next one available is 4.3-1, which introduces the bug I've explained. I can confirm bug and fix. Using Dell XPS 13 2016 running openSUSE Tumblweed. Either kernel 4.4.5 or 4.5.0 with the i915.enable_rc5=0 fix the flickering (In reply to Mauro Morales from comment #7) > I can confirm bug and fix. Using Dell XPS 13 2016 running openSUSE > Tumblweed. Either kernel 4.4.5 or 4.5.0 with the i915.enable_rc5=0 fix the > flickering Carlo, please re-test and confirm that it is indeed fix on your side. As reported in the initial bug report I stated that enable_rc6 does resolve my issue, but I believe it to be a temporary fix for some. I believe it is temporary as Francisco Lopes mentioned that this helps his primary display but is not a fix for a secondary display. I'm not sure about enable_rc5, but if it works for some it might also be a valid temporary fix. (In reply to Carlo Abelli from comment #9) > I'm not sure about enable_rc5, but > if it works for some it might also be a valid temporary fix. If i915.enable_rc5 helps anyone, it's a placebo effect. (That parameter does not exists.) (In reply to Jani Nikula from comment #10) > If i915.enable_rc5 helps anyone, it's a placebo effect. > > (That parameter does not exists.) That's what I thought. enable_rc6 does appear to be a temporary fix though and I can confirm that. I'd like to comment that the second issue I mention, in the secondary display, which is an intermittent ON/OFF of the screen, may be possibly unrelated with the screen flicker. While making various tests, I noticed flickering shown up because the secondary display has been connected once, afterwards, anytime I moved my mouse/touchpad, the primary display flickered, hence I thought these two issues could be related. I've applied a flag on boot that worked to remove the flickering, but did nothing about screen ON/OFF, the only solution for this was to downgrade the kernel further. Dell Precision 5510 with i7-6820HQ, running Debian unstable with Linux 4.5.3. I have the same symptoms: flickering screen, plus "*ERROR* CPU pipe A FIFO underrun" messages when running 4.5.x, not when running 4.4.x. Using enable_rc6=0 seems to remove both flickering and error message. I have A Dell Precision 7510 with a Intel I7-6820HQ running Xubuntu 16.04 LTS, when using Linux Kernel 4.5 or newer i experience screen flicker (the screen flashes black. I would like to add that besides the screen flickering I also have the drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun on my notebook. I have a Dell Precision 5510 with the i5-6300HQ running Fedora 23 and I am also experiencing the flickering and the error message: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun The problem for me has also started once moving to kernel 4.5.X from 4.4.X. I am currently running 4.5.5 and the bug persists. Specifically in my case, the flickering does not occur when I am using a second monitor, but it does occur when I am using just the laptop's flat panel. Initial testing indicates for me that the flickering is *not* occurring on 4.6.1 even without the i915.enable_rc6=0 trick. If this remains the case and others also see the same improvement I will come back and comment this as resolved. Sadly for me 4.6.1 had no effect. I still have intermittent ON/OFF (WiFi stopped on upgrade too). Downgrading back to 4.2.5-1. (In reply to Francisco Lopes from comment #12) > I'd like to comment that the second issue I mention, in the secondary > display, which is an intermittent ON/OFF of the screen, may be possibly > unrelated with the screen flicker. > > While making various tests, I noticed flickering shown up because the > secondary display has been connected once, afterwards, anytime I moved my > mouse/touchpad, the primary display flickered, hence I thought these two > issues could be related. > > I've applied a flag on boot that worked to remove the flickering, but did > nothing about screen ON/OFF, the only solution for this was to downgrade the > kernel further. This intermittent ON/OFF feels like what we (at work) se on our HP ProBook laptops(Broadwell) for external monitors. We use latest 4.4.12 (.13 not tested yet). People here workaround the issue by downgrading to 4.1.20. I am told the i915.enable_rc6=0 does NOT help. We also see the [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun message (In reply to Joakim Tjernlund from comment #19) > (In reply to Francisco Lopes from comment #12) > > I'd like to comment that the second issue I mention, in the secondary > > display, which is an intermittent ON/OFF of the screen, may be possibly > > unrelated with the screen flicker. > > > > While making various tests, I noticed flickering shown up because the > > secondary display has been connected once, afterwards, anytime I moved my > > mouse/touchpad, the primary display flickered, hence I thought these two > > issues could be related. > > > > I've applied a flag on boot that worked to remove the flickering, but did > > nothing about screen ON/OFF, the only solution for this was to downgrade the > > kernel further. > > This intermittent ON/OFF feels like what we (at work) se on our HP ProBook > laptops(Broadwell) for external monitors. > > We use latest 4.4.12 (.13 not tested yet). People here workaround the > issue by downgrading to 4.1.20. > > I am told the i915.enable_rc6=0 does NOT help. > We also see the > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO > underrun > message 4.4.13 tested now, same ON/OFF problem. Also, it only happens when having monitors over DP, VGA works fine. I also have this on Mac Book Pro (13' 2015) with Arch 4.6.2.1 (x86_64) Output of 'lspci | grep "VGA|3D"' 00:02.0 VGA compatible controller: Intel Corporation Iris Graphics 6100 (rev 09)[/code] I have seen the FIFO underrun but I haven't seen it recently. I'm running i3 and have the following drivers: xf86-video-fbdev 0.4.4-5 xf86-video-intel 1:2.99.917+662+gb617f80-1 xf86-video-vesa 2.3.4-2 Booting with "i915.enable_rc6=0" doesn't seem to have fixed it and the flickering seems to be independant of external screens. I also have this on Mac Book Pro (13' 2015) with Arch 4.6.2.1 (x86_64) Output of 'lspci | grep "VGA|3D"' 00:02.0 VGA compatible controller: Intel Corporation Iris Graphics 6100 (rev 09)[/code] I have seen the FIFO underrun but I haven't seen it recently. I'm running i3 and have the following drivers: xf86-video-fbdev 0.4.4-5 xf86-video-intel 1:2.99.917+662+gb617f80-1 xf86-video-vesa 2.3.4-2 Booting with "i915.enable_rc6=0" doesn't seem to have fixed it and the flickering seems to be independant of external screens. I also see this issue on a Toshiba Chromebook 2 running Arch Linux. Kernel 4.4.4 is fine, kernels 4.5 and 4.6 have flickering. "lshw -C display" reports description: VGA compatible controller product: Atom Processor Z36xxx/Z37xxx Series Graphics & Display vendor: Intel Corporation physical id: 2 bus info: pci@0000:00:02.0 version: 0e width: 32 bits clock: 33MHz capabilities: pm msi vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:263 memory:d0000000-d03fffff memory:c0000000-cfffffff ioport:1000(size=8) i915.enable_rc6=0 does not fix the problem for me. Hi, I'd just like to inform that the intermittent ON/OFF issue I've mentioned before that was affecting me is not happening anymore, I'm now on Kernel 4.6.4 and finally none of this flickering and ON/OFF issues is happening anymore. I have the flickering/gray screen issue with an ASUS Zenbook UX303L running Arch Linux (kernel 4.7-1). Output of lshw -C display: description: VGA compatible controller product: HD Graphics 5500 vendor: Intel Corporation physical id: 2 bus info: pci@0000:00:02.0 version: 09 width: 64 bits clock: 33MHz capabilities: msi pm vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: memory:a2000000-a2ffffff memory:c0000000-cfffffff memory:d0000000-d1ffffff ioport:3000(size=128) memory:a3000000-a307ffff I do not have any xf86-video-* drivers installed. dmesg reports two different errors related to the display: [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Please try the last drm-intel-nightly from http://cgit.freedesktop.org/drm-intel and report back. (In reply to Rami from comment #26) > Please try the last drm-intel-nightly from > http://cgit.freedesktop.org/drm-intel and report back. Actually, 4.4.19 fixed the problem for me Kernel 4.7.4 fixes the flickering for me. Thank you! I am still experiencing this issue with the the same error messages on kernel 4.7.4. (In reply to Carlo Abelli from comment #9) > As reported in the initial bug report I stated that enable_rc6 does resolve > my issue, but I believe it to be a temporary fix for some. I believe it is > temporary as Francisco Lopes mentioned that this helps his primary display > but is not a fix for a secondary display. I'm not sure about enable_rc5, but > if it works for some it might also be a valid temporary fix. Hello Carlo. Is the problem fixed for you, specifically, without the use of i915.enable_rc6? A note to everybody: we are aware of multiple problems that end up in "FIFO underrun" messages on Skylake. The problem is that bugs get really hard to manage when there are multiple users with multiple machines claiming they all have the same bug, then some users claiming that the bug got fixed for them, some other users claiming the bug still happens. It's much easier for us developers to close duplicates than to "fork" multiple bugs in a single report. So my proposal here is: if Carlo confirms the bug is indeed fixed for him, we close this bug report and ask everybody else to submit new bug reports with the relevant information for their specific systems. Also, for everybody else still affected, please test the latest drm-intel-nightly tree since we recently merged some more fixes related to this (these fixes are going to land in stable Kernels at some point, but it's better if you can test now and report any remaining issues). This bug is fixed for me and I was only keeping it open due to others who seemed to have the same issue. Since there do appear to be various bugs, I agree with your stance to close this bug and have the others open new bug reports. (In reply to Carlo Abelli from comment #31) > This bug is fixed for me and I was only keeping it open due to others who > seemed to have the same issue. Since there do appear to be various bugs, I > agree with your stance to close this bug and have the others open new bug > reports. Thanks. People still seeing issues on current drm-intel-nightly, please file new bugs. For reference, there are additional fix that may benefits : Paulo's patch to apply memory workarounds for skylake: https://patchwork.freedesktop.org/series/13548/ I am on Kernel 4.11.3 and experiencing this glitching. Moving the mouse seems to temporarily stop the glitching, but otherwise there seems to be serious screen jitter I am on ArchLinux with kernel 4.12.4-1-ARCH and the problem still is present. Using the kernel parameter "i915.enable_rc6=0" makes it go away. lspci -v output: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 1507 Flags: bus master, fast devsel, latency 0, IRQ 32 Memory at f7400000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 dmesg snippet: [ 54.358770] Setting dangerous option enable_rc6 - tainting kernel [ 54.359634] [drm] Memory usable by graphics device = 2048M [ 54.359636] checking generic (d0000000 7f0000) vs hw (d0000000 10000000) [ 54.359637] fb: switching to inteldrmfb from EFI VGA [ 54.359662] Console: switching to colour dummy device 80x25 [ 54.359765] [drm] Replacing VGA console driver [ 54.365161] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 54.365163] [drm] Driver supports precise vblank timestamp query. [ 54.368216] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 54.383304] [drm] RC6 disabled, disabling runtime PM support [ 54.384426] [drm] Initialized i915 1.6.0 20170403 for 0000:00:02.0 on minor 0 [ 54.384592] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 54.385527] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input17 [ 54.386294] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 54.401527] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input18 HTH this might be the place to track this for others who are still having the issue: https://bugs.freedesktop.org/show_bug.cgi?id=97918 (In reply to kxra from comment #36) > this might be the place to track this for others who are still having the > issue: https://bugs.freedesktop.org/show_bug.cgi?id=97918 or rather here: https://bugs.freedesktop.org/show_bug.cgi?id=101586 |
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.