I would like to report a severe graphics regression, involving frequent rainbow-glitching and flickering on a x64 computer with Intel Broadwell 5500U processor w/ integrated graphics. This issue was not present on kernel v4.7.4, which I will continue to use. Due to unfortunate issues with Broadwell integrated graphics support, virtually every kernel build in the 4.8 release chain as well as the newest v4.7.5 kernel have this issue. Dramatic multicolored patches and glitched areas appear frequently when using my computer with these kernels installed. The behavior is very similar to that of the Broadwell graphics issues present in kernel version 4.6.x. Please fix this issue, I don't understand why NEWER kernels are actually causing significant graphical problems with older hardware.
The following is my system configuration: H/W path Device Class Description ==================================================== system HP Spectre x360 Convertible (N5R94UA#ABA) /0 bus 802D /0/0 memory 64KiB BIOS /0/10 memory 32KiB L1 cache /0/11 memory 32KiB L1 cache /0/12 memory 256KiB L2 cache /0/13 memory 4MiB L3 cache /0/14 processor Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz /0/16 memory 8GiB System Memory /0/16/0 memory 4GiB Row of chips Synchronous 1600 MHz (0.6 ns) /0/16/1 memory 4GiB Row of chips Synchronous 1600 MHz (0.6 ns) /0/100 bridge Broadwell-U Host Bridge -OPI /0/100/2 display Broadwell-U Integrated Graphics /0/100/3 multimedia Broadwell-U Audio Controller /0/100/14 bus Wildcat Point-LP USB xHCI Controller /0/100/14/0 usb2 bus xHCI Host Controller /0/100/14/1 usb1 bus xHCI Host Controller /0/100/14/1/1 input USB Receiver /0/100/14/1/3 multimedia HP Truevision Full HD /0/100/14/1/4 input Touchscreen /0/100/14/1/5 input ITE Device(8350) /0/100/14/1/7 communication Bluetooth wireless interface /0/100/16 communication Wildcat Point-LP MEI Controller #1 /0/100/1b multimedia Wildcat Point-LP High Definition Audio Controller /0/100/1c bridge Wildcat Point-LP PCI Express Root Port #2 /0/100/1c/0 generic RTS5227 PCI Express Card Reader /0/100/1c.2 bridge Wildcat Point-LP PCI Express Root Port #3 /0/100/1c.2/0 wlo1 network Wireless 7265 /0/100/1f bridge Wildcat Point-LP LPC Controller /0/100/1f.2 storage Wildcat Point-LP SATA Controller [AHCI Mode] /0/100/1f.3 bus Wildcat Point-LP SMBus Controller /0/1 scsi0 storage /0/1/0.0.0 /dev/sda disk 512GB SAMSUNG MZNTE512 /0/1/0.0.0/1 /dev/sda1 volume 449MiB Windows NTFS volume /0/1/0.0.0/2 /dev/sda2 volume 98MiB Windows FAT volume /0/1/0.0.0/3 /dev/sda3 volume 15MiB reserved partition /0/1/0.0.0/4 /dev/sda4 volume 15EiB Windows FAT volume /0/1/0.0.0/5 /dev/sda5 volume 807MiB Windows NTFS volume /0/1/0.0.0/6 /dev/sda6 volume 97GiB Windows NTFS volume /0/1/0.0.0/7 /dev/sda7 volume 89GiB EXT4 volume /0/1/0.0.0/8 /dev/sda8 volume 8098MiB Linux swap volume /1 power PK03056XL
It should be an easy bisect between v4.7.4 and v4.7.5. AFAICT the only change would be commit d18accc4ef53cc91b93384a5227b787a47f321b4 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 13 12:22:19 2016 +0300 drm/i915: Ignore OpRegion panel type except on select machines commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 upstream. and here the earlier regression trumps, which is unfortunate for you.
I propose a patch that can be applied from within the kernel source directory for compilation that merely reverts those changes, let's call it broadwell-gfx-fix.patch, which can be applied with patch -p1 < broadwell-gfx-patch I am currently compiling the kernel with this patch in addition to the default kernel patches at http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.5/ and hoping for the best! The contents were generated by diff -u as follows: --- linux-4.7.5/drivers/gpu/drm/i915/intel_opregion.c 2016-09-24 04:10:18.000000000 -0400 +++ linux-4.7.4/drivers/gpu/drm/i915/intel_opregion.c 2016-09-15 02:21:53.000000000 -0400 @@ -1013,23 +1013,6 @@ return err; } -static int intel_use_opregion_panel_type_callback(const struct dmi_system_id *id) -{ - DRM_INFO("Using panel type from OpRegion on %s\n", id->ident); - return 1; -} - -static const struct dmi_system_id intel_use_opregion_panel_type[] = { - { - .callback = intel_use_opregion_panel_type_callback, - .ident = "Conrac GmbH IX45GM2", - .matches = {DMI_MATCH(DMI_SYS_VENDOR, "Conrac GmbH"), - DMI_MATCH(DMI_PRODUCT_NAME, "IX45GM2"), - }, - }, - { } -}; - int intel_opregion_get_panel_type(struct drm_device *dev) { @@ -1055,16 +1038,6 @@ return -ENODEV; } - /* - * So far we know that some machined must use it, others must not use it. - * There doesn't seem to be any way to determine which way to go, except - * via a quirk list :( - */ - if (!dmi_check_system(intel_use_opregion_panel_type)) { - DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1); - return -ENODEV; - } - /* * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us * low vswing for eDP, whereas the VBT panel type (2) gives us normal
I can confirm the 4.7.5 regression. Didn't test 4.8 yet. Same flickering problem as for 4.6.x was https://bugs.freedesktop.org/show_bug.cgi?id=95176 . 4.7.0 - 4.7.4 were ok in this regard. My hardware same as above (Intel Broadwell 5500U). I can only sum it up with the quote from Godfather part III: "Just when I thought I was out... they pull me back in" :)
So the part that will suck for you is that apparently the original commit *fixed* stuff for you, while it broke stuff for others. Unfortunately, it is the earlier regression that trumps newer regressions. :(
Ok, but if I read the patch correctly it doesn't remove anything, just add some conditional and whitelist. If it's true then adding new hardware to it is possible. Otherwise we're back to square one https://bugs.freedesktop.org/show_bug.cgi?id=95176 . BTW: Isn't this comment about the same thing? /* * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us * low vswing for eDP, whereas the VBT panel type (2) gives us normal * vswing instead. Low vswing results in some display flickers, so * let's simply ignore the OpRegion panel type on SKL for now. */ if (IS_SKYLAKE(dev)) { DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1); return -ENODEV; } return ret - 1; } Maybe this could fix flickering for broadwell as well
No, no the patch actually removes those 20 or so lines in intel_opregion.c that were added in 4.7.5 but not present in 4.7.4. I can confirm that this fix does work, and is perfectly safe because the lines deleted were static functions that remained unused outside of that file. I successfully compiled and installed my patched 4.7.5 kernel, and there are no artifacts or display issues :D I created a git repository with the patched kernel specifically for use with a laptop with an Intel Broadwell U series processor. Simply install the .deb files in my git repository I generated from compiling the patched kernel and you should be running the latest and greatest stable kernel without issue! https://github.com/nstommel/Linux_Kernel_v4.7.5_Broadwell_i915_graphics_patch Hope this helps anyone experiencing graphics issues with the v4.7.5! I've been running my custom kernel for several days now and everything is working very well. I've also noticed an improvement in battery life with the newer kernel over the stock v4.4.x kernel provided in Ubuntu by default.
The patch file can be found here as well if you want to compile the kernel source yourself: https://github.com/nstommel/Linux_Kernel_v4.7.5_Broadwell_i915_graphics_patch/blob/master/patches/0007-broadwell-gfx-fix.patch
Actually I meant the original patch from 4.7.5 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/drivers/gpu/drm/i915/intel_opregion.c?id=v4.7.5&id2=v4.7.4 which was the root of our issues not your hotfix (which reverts it).
Created attachment 126978 [details] [review] Add Hp Spectre x360 to OpRegion whitelist I managed to fix the issue by adding my hardware to whitelist created by mentioned patch above.
Created attachment 126979 [details] /sys/kernel/debug/dri/0/i915_vbt HP Spectre x360 Convertible 13 I know from https://bugs.freedesktop.org/show_bug.cgi?id=97992 that adjusting whitelist isn't welcomed so I add same info requested there. I hope it helps.
Created attachment 127004 [details] diff -u between 4.7.4 intel_opregion.c and 4.8 intel_opregion.c So there were quite a few changes in the intel_opregion.c file from 4.7.4 to 4.8. See the attached diff file. However, the very same lines that disable the opregion panel can be removed, and successfully resolve this issue.
Created attachment 127005 [details] [review] kernel patch for intel_opregion.c in v4.8 Attached is the patch for intel_opregion.c that works for compiling Linux kernel 4.8. Please note that no fix has been provided upstream, and I have also tested the latest Ubuntu 16.10 distribution that comes with a custom 4.8 kernel and the graphics problems with Broadwell integrated graphics persist. Aside from adding the HP Spectre x360 to a whitelist, which was not recommended, this appears to be the only fix. If anyone is interested, I have uploaded patched .deb kernel packages to my new github page at https://github.com/nstommel/Linux-Kernel-Broadwell-i915-graphics-patch The separate patches for 4.7.4+ and 4.8+ are also located on my page. I hope this helps, I we are unfortunately stuck with having to patch the kernel for certain laptops with Broadwell integrated graphics :/ Also, the whitelisting fix may not work, as my dmidecode output was actually different from the suggested one, and looks like: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: HP Product Name: HP Spectre x360 Convertible
Yes, when you revert last commit it fixes the issue (you already wrote about it couple of times before) but as Jani wrote it can't be reverted upstream because of earlier regression. To fix it through whitelist you need to specify each device one by one so it isn't a longterm solution too. I wonder what additional info is needed for devs to finally solve those puzzle.
This issue is persistent in kernel 4.8, including the kernel v4.8x in the latest Yakkety 16.10 build. Is there any way that a fix for this processor/hardware combination could be added upstream so we don't end up recompiling the kernel until the end of time here? This is a serious problem, my laptop is almost unusuable when opregion panel support is disabled (which is the case for every single kernel version after 4.7.4).
Created attachment 127232 [details] [review] Patch for 4.8.1 Here's the patch for kernel v4.8.1 and the .deb packages are available at my github page at https://github.com/nstommel/Linux-Kernel-Broadwell-i915-graphics-patch
Is anyone working on it? Is it possible to add some option like i915.use_opregion=1 or something to make everyone happy until it's finally resolved? Current situation with whitelisted one lucky guy and blacklisted everyone else isn't very admirable.
Kernel 4.9 has once again caused the weird display artifacting and occasional rainbow glitching/flickering. The aforementioned patch no longer fixes the problem, something new must be causing this issue now. Unfortunately, I have no idea where this problem might occur because there were thousands of lines changed in the drivers/gpu/drm/i915 folder between 4.8.x and 4.9. Any support would be welcome here, this is an unfortunate graphics issue. For the time being, I'm stuck on 4.8.x with Broadwell U graphics. Again, the intel_opregion.c file was NOT changed, it must be something else among the i915 changes.
Highest+Blocker as being regression w/o workaround
This appears to be an issue with the low_vswing vbt setting. If low vswing is causing the issue there is a kernel parameter that overrides the setting. Please try: i915.edp_vswing=2 This forces 'high' 400mv vswing settings.
Based on the comment 18 assumable this should be bisected again. Nicholas, see also comment 20 for proposed workaround.
Finally I updated kernel to 4.9 series so I can give you some feedback. All tests performed with version 4.9.8 booting with i915.enable_psr=1 -> flickering occurs randomly booting with i915.enable_psr=1 i915.edp_vswing=2 -> flickering still occurs randomly recompiling kernel with whitelist patch https://bugs.freedesktop.org/attachment.cgi?id=126978 and booting with i915.enable_psr=1 -> all clear, no flickering! Conclusion: nothing really changes from previous kernels. Using OpRegion panel type is still needed for this device to work properly. I'm not sure about Nicholas but my hardware is 98% identical to his. The reason he noticed breakup with 4.9 kernel could be that he used to revert the "infamous" commit d18accc4ef53cc91b93384a5227b787a47f321b4 instead of whitelisting his device which could conflict with recent code changes. I wonder what's the ratio between devices which should use Opregion and those which shouldn't. The proper fix could be to automatically direct device to one of those groups. As a temporary workaround it would be nice to have runtime switch to force using OpRegion panel type as recompiling every new kernel with 4 lines of code is nuts especially with flood of kernel updates in recent times.
Okay, so it appears like I may have incorrectly patched the kernel in my first attempt, because now whitelisting or removing the 20 or so lines from kernel 4.9.x seems to work totally fine. The original regression though is still quite annoying, as I have had to patch every single kernel since 4.7.5 so that the opregion interface remains enabled on the Spectre x360.
This comment is just to report that as user i'm facing the same issue on a spectre x360 with the same configuration. The up to date patchset here developed is working for me as by https://github.com/nstommel/broadwell-gfx-kernel-patch and i'm obviously looking forward for having it delivered upstream and shipped in Debian/Ubuntu to avoid installing a not signed kernel. Thank you so much for your time debugging this!
Removing status of Needinfo seems that all information has been provided. Also I read correctly and seems that the issue is now solved?
It isn't solved. Nothing changed since bug was reported. It needs https://bugs.freedesktop.org/attachment.cgi?id=126978 or https://bugs.freedesktop.org/attachment.cgi?id=127232 as workarounds.
Both workarounds are not present in the top of drm-tip. Commit: 30424f2. Kernel: 4.10.0.
Can everyone please make sure they've disabled the legacy support/CSM/whatever option in their BIOS setup? That has turned out to be the solution to other bugs where the VBT seems to contain nonsense (eg. bug 97822) Most vendors only test native UEFI with Windows so everything else tends to be horribly broken.
Hrmh, all this talk and no dmesg with drm.debug=14 or anything. Which we could have used to check the boot mode too.
Created attachment 130131 [details] HP Spectre x360 Convertible 13 dmesg Well, nobody asked :) As you wish, here is my dmesg. I had to suspend/resume to trigger flickering as it occurs randomly - sometimes nothing for hours, sometimes many for couple of minutes.
(In reply to Mark Spencer from comment #30) > Well, nobody asked :) The frustration was vaguely aimed at nobody asking, not at the reporters. Sorry. Looks like an EFI boot to me.
Created attachment 130330 [details] [review] Patch for 4.9.15+ There were some changes made in the 4.9.x source to the file, so this patch works for 4.9.15+ (the same lines are removed, just different line numbers obviously). For anyone who has the display artifacting problem with the opregion interface, this patch is for your convenience.
Thanks for posting patches... but for them to be considered, you'd have to be running drm-tip branch of https://cgit.freedesktop.org/drm/drm-tip and test against that.
This "patch" only reverts https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/drivers/gpu/drm/i915/intel_opregion.c?id=v4.7.5&id2=v4.7.4 so I think Nicholas posts it only as quickfix not an upstream candidate. Personally I use whitelist created by the above commit which has more guarantee to work with every new kernel but needs to be more specific about actual hardware.
It's strange thing but it looks that I can't reproduce flickering with kernel 4.9.21 anymore. It occurred for sure with 4.9.13. I see there was a patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/drivers/gpu/drm/i915/intel_opregion.c?id=v4.9.13&id2=v4.9.22 Anyone can confirm this?
I finally reproduced some flickering but it's very rare.
I have flickering very very rare too, but I have noticed, that when firefox is open flickering occures far more often. May be it helps reproduce issue.
Oops. Seems to flickering on my system has disppeared with latest kernel (4.10.12)
Looks like the problems is no longer present, please if the problem persist reopen the bug... moving to resolved
Hello, I'm new here. I have just purchased a HP Spectre x360 - 15-bl003nf Intel® Core™ i7-7500U NVIDIA® GT 940MX and I have the exact same problem whatever the graphic card drivers I use. I have tested without success the following kernels : v 4.8.0 v 4.9.37 v 4.12 So I have reverted back to the kernel 4.7.4 and now all is working fine (but some stuff doesn't work in 4.7.4 like the stylus and the touch) I haven't yet tested the patched kernels. I just learned to use Ukuu, so I need to know more how to proceed with them before trying. I think you should reopen the Bug 97918.
Huh...fascinating. You can download the two debian packages from my github repository at https://github.com/nstommel/broadwell-gfx-kernel-patch/tree/master/4.9/4.9.21 No need to bother patching it yourself, that's why I uploaded the prepackaged headers and image .debs. Installation is quite easy, really. In a terminal after downloading the two package files (don't clone the repository, just download the headers and image .debs from the repo webpage, type cd ~/Downloads sudo dpkg -i linux-headers-4.9.21_Custom_amd64.deb linux-image-4.9.21_Custom_amd64.deb On bootup, select 4.9.21 in the GRUB Advanced Options menu. I should note, however, that your machine actually has a dedicated nvidia graphics card, so theoretically this would not affect you at all if you made sure that your Linux installation is actually using the dedicated card and not integrated Intel graphics. Try searching for drivers in the system settings application. Unless you actually want to not use the nvidia card for some reason, in which case please try installing my patched version of 4.9.21. It's interesting this is a problem with the Kabylake processor as well.
Hi Nicholas, Thanks for answering so fast. I can't do the tests today and tomorrow (I'm in the middle of business trip), but I will probably on wednesday or thrusday.
Fabrice, The new HP Spectre x360 uses an Nvidia 940mx discrete video chip. Changing the Intel i915 graphics driver will not help solve your issue. This issue is specifically for the Broadwell chipset and a very specific panel/bios configuration. Please reopen this issue if you have this specific configuration. Thanks.
Fabrice, Actually the Nvidia 940mx is using a dual GPU setup very similar to the Broadwell version of the x360. Please test with Nicholas's kernel and post the results here. Thanks, Clint
ok, I just tested the patched kernel and it works fine, without flickering. That's cool. Regarding the video card in use, I'm not 100% sure of which one Mint is currently using (NVidia or Intel). The drivers manager says I have a NVIDIA GM108M (in use with an open-source driver) + an unknown card. So I guess I'm using NVIDIA.
Hello, I'm not sure it someone will debug this issue in a new kernel. So what is the process to patch it by myself ?
(In reply to Fabrice D. from comment #46) > Hello, > > I'm not sure it someone will debug this issue in a new kernel. > > So what is the process to patch it by myself ? Hello Fabrice, You can use git am and then rebuild the kernel again. For extra help you can ask in the community Forums: https://01.org/linuxgraphics/community, and over the internet, like for example: https://stackoverflow.com/questions/2249852/how-can-i-apply-a-patch Thanks.
Sorry, so is this fixed and if so, in what version? I have this issue on the Lenovo YOGA-910-13IKB running the 4.11.11 kernel on Fedora 26. Is i915.enable_rc6=0 the best workaround? Here is my lspci: ~]$ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 02) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02) 00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 02) 00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21) 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21) 00:15.3 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #3 (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1) 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
okay, I have just upgraded to kernel 4.12.5 and the screen tearing / flickering still makes the system unusable but it isn't constant as before. not sure if this is connected to a change or just cooincidence, since the problem is still present
(In reply to kxra from comment #49) > okay, I have just upgraded to kernel 4.12.5 and the screen tearing / > flickering still makes the system unusable but it isn't constant as before. > not sure if this is connected to a change or just cooincidence, since the > problem is still present This bug is about flickering in BDW - this case is related to KBL based on comment 48 - let's not mix these. kxra@riseup.net , please provide dmesg having drm.debug=0x1e log_buf_len=1M used on kernel command line (see https://01.org/linuxgraphics/documentation/how-report-bugs) into one of the bugs given below query. Or if none of below bugs apply then please create new one for KBL. https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=DRM%2FIntel&f1=cf_i915_platform&list_id=621946&longdesc=flick&longdesc_type=substring&o1=substring&product=DRI&query_format=advanced&v1=KBL
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
(In reply to Jari Tahvanainen from comment #50) > (In reply to kxra from comment #49) > > okay, I have just upgraded to kernel 4.12.5 and the screen tearing / > > flickering still makes the system unusable but it isn't constant as before. > > not sure if this is connected to a change or just cooincidence, since the > > problem is still present > > This bug is about flickering in BDW - this case is related to KBL based on > comment 48 - let's not mix these. kxra@riseup.net , please provide dmesg > having drm.debug=0x1e log_buf_len=1M used on kernel command line (see > https://01.org/linuxgraphics/documentation/how-report-bugs) into one of the > bugs given below query. Or if none of below bugs apply then please create > new one for KBL. > https://bugs.freedesktop.org/buglist. > cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOP > ENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=NEEDINFO&bug_status=P > LEASETEST&component=DRM%2FIntel&f1=cf_i915_platform&list_id=621946&longdesc=f > lick&longdesc_type=substring&o1=substring&product=DRI&query_format=advanced&v > 1=KBL thanks, I added to this: https://bugs.freedesktop.org/show_bug.cgi?id=101586
hmmmm ... not sure about the comment #51 (I'm new here, sorry) Does that mean that a developper will handle this problem ?
*** This bug has been marked as a duplicate of bug 101111 ***
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.