|Summary:||Intel GeminiLake corruption at top of screen caused by fbc|
|Product:||DRI||Reporter:||Daniel Drake <dan>|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Priority:||medium||CC:||arkadiusz.hiler, intel-gfx-bugs, lui, przanoni, punx665|
|i915 platform:||GLK||i915 features:||display/FBC|
|Bug Depends on:|
Description Daniel Drake 2018-09-27 09:07:02 UTC
On Intel GeminiLake platforms, a horizontal line of display corruption frequently appears at the top of the screen. This seems to happen on every single GeminiLake platform that we try. Affected units include Asus E406MA and Acer Aspire XC-830. We also have enough systems on hand to confidently say that it does not affect ApolloLake, KabyLake, CoffeeLake nor WhiskeyLake. It is reproducible: * On Fedora 28 with all updates (Linux 4.18, mesa-18.0) on both X and wayland. * On Fedora 29 beta (Linux 4.18, mesa 18.2) with all updates, under wayland * On Endless OS with Linux 4.19-rc5 and also on today's linux-next Reproducer: at gdm, repeatedly click on the time/date to open and close the calendar several times. Alternative reproducer, a bit harder: open terminal, run dmesg, maximize the terminal, then use two-finger scroll to quickly scroll up and down. A video showing the problem under Endless. (note that Endless has modified gdm to eliminate time/date at the top, so I instead reproduce by opening and closing a menu repeatedly) https://youtu.be/JUAr8sBwrmc Another video showing that sometimes the corruption persists for a long time. It's a bit hard to see in the video, but I can move the mouse over the corrupted area and while the corruption persists underneath, the mouse cursor itself is rendered just fine. https://youtu.be/CWRgTo9KrwI I can't reproduce if I run with LIBGL_ALWAYS_SOFTWARE=1 When the corruption persists on screen, if I take a screenshot with "DISPLAY=:0 import -window root out.png", the captured output is fine (it does not show the corruption) Please let me know how I can help debug further
Comment 1 Daniel Drake 2018-09-27 09:33:43 UTC
Created attachment 141758 [details] lspci output on Asus E406MA
Comment 2 Daniel Drake 2018-09-27 09:34:05 UTC
Created attachment 141759 [details] glxinfo output on Asus E406MA
Comment 3 Chris Wilson 2018-09-27 10:43:51 UTC
(In reply to Daniel Drake from comment #0) > On Intel GeminiLake platforms, a horizontal line of display corruption > frequently appears at the top of the screen. > > When the corruption persists on screen, if I take a screenshot with > "DISPLAY=:0 import -window root out.png", the captured output is fine (it > does not show the corruption) Suggests that it may be a display engine issue (or a really weird resolve, but I'd bet on a conflict in stolen memory). A drm.debug=0xe may be helpful.
Comment 4 Mark Janes 2018-09-27 12:47:40 UTC
reminds me of the Zalgo bug.
Comment 5 Daniel Drake 2018-09-28 06:31:31 UTC
Created attachment 141770 [details] drm.debug=0xe log When the corruption happens, the only lines that are logged are the drm_mode_addfb2 messages which occur every time the screen content changes (even in the no-corruption case).
Comment 6 Alexey 2018-09-29 18:28:28 UTC
Have exactly the same issue on my Lenovo Ideapad 330-15IGM with Intel N5000 inside under Xubuntu 18.04.
Comment 7 Jani Nikula 2018-10-08 06:57:06 UTC
A shot in the dark, please try i915.enable_dc=0 and i915.disable_power_well=0, separately, one at a time.
Comment 8 Daniel Drake 2018-10-08 07:12:13 UTC
I tried both options separately, the corruption still easily reproduced in both cases. BTW we would be prepared to ship a sample product to Intel if that helps.
Comment 9 Paulo Zanoni 2018-10-16 18:12:34 UTC
First 4kb of stolen memory being used? Aka possible regression from commit 011f22eb545a35f972036bb6a245c95c2e7e15a0. At drivers/gpu/drm/i915/i915_gem_stolen.c, function i915_gem_init_stolen(), at the very end, on the drm_mm_init() call, can you please change the second argument from 0 to 4096? Also please in the stolen_usable_size argument right above this, subtract 4096 to compensate that. Then please test this and report if the problem still happens.
Comment 10 Daniel Drake 2018-10-17 05:10:59 UTC
Created attachment 142067 [details] [review] suggested change Thanks Paulo. I made this code change according to your suggestion however it does not seem to affect the issue, the corruption is still present.
Comment 11 Rodrigo Vivi 2018-10-18 00:46:15 UTC
Daniel, could you please try to disable FBC? Also, did you try an older kernel to see if this is a regression and possible bisectable?
Comment 12 Daniel Drake 2018-10-18 05:17:10 UTC
i915.enable_fbc=0 makes the issue go away Re-enabling fbc, I also tried INTEL_DEBUG=norbc for mesa but the issue is still there. So this seems to be a bug with the i915 kernel driver framebuffer compression, I'm adjusting the bug accordingly.
Comment 13 Daniel Drake 2018-10-18 05:32:31 UTC
Also tested Linux 4.13 which was the first kernel to support GeminiLake without requiring alpha_support. The bug is immediately reproducible there so it does not seem to be a regression. Again, booting that kernel with i915.enable_fbc=0 the issue goes away.
Comment 14 Lakshmi 2018-10-18 07:23:04 UTC
Daniel, Thanks for the detailed bug report/videos. (In reply to Daniel Drake from comment #0) > On Intel GeminiLake platforms, a horizontal line of display corruption > frequently appears at the top of the screen. Does this happen throughout the usage of the PC or only at gdm? > Alternative reproducer, a bit harder: open terminal, run dmesg, maximize the > terminal, then use two-finger scroll to quickly scroll up and down. In this case, even though it is hard to reproduce the issue, corruption will stay forever? or disappears?
Comment 15 Daniel Drake 2018-10-18 08:01:02 UTC
(In reply to Lakshmi from comment #14) > Does this happen throughout the usage of the PC or only at gdm? It happens throughout usage, but gdm the easiest way to reproduce it on-demand that I've found. > > Alternative reproducer, a bit harder: open terminal, run dmesg, maximize the > > terminal, then use two-finger scroll to quickly scroll up and down. > > In this case, even though it is hard to reproduce the issue, corruption will > stay forever? or disappears? If you manage to stop scrolling right at the moment when the corruption is visible, then the corruption will persist until the next screen update. Otherwise, it will disappear after a moment.
Comment 16 Daniel Drake 2018-10-22 05:57:58 UTC
Even though it's for a different SoC I checked on a few details found in https://www.x.org/docs/intel/SKL/rev01/intel-gfx-prm-osrc-skl-vol16-workarounds.pdf 0529: enabled the existing i915 codepath on GLK, no change 0562: FBC Watermark Disable is already set 0622: don't know how to check this 0851: don't know how to check this 0859: DISP_FBC_MEMORY_WAKE is already set 0873: added ILK_DPFC_NUKE_ON_ANY_MODIFICATION, no change 0883: ILK_DPFC_DISABLE_DUMMY0 is already set, DISP_FBC_MEMORY_WAKE is already set 0884: i915 implementation only affects PSR codepath but this platform doesn't support PSR So no progress there, further suggestions very welcome...
Comment 17 Alexey 2018-10-23 08:58:54 UTC
Can confirm i915.enable_fbc=0 solved the issue in my system.
Comment 18 Jani Nikula 2018-10-24 09:49:54 UTC
Random idea, does intel_iommu=igfx_off make a difference with fbc enabled?
Comment 19 Daniel Drake 2018-10-25 05:00:44 UTC
(In reply to Jani Nikula from comment #18) > Random idea, does intel_iommu=igfx_off make a difference with fbc enabled? The visual corruption is still easily reproducible with that parameter.
Comment 20 Lakshmi 2018-11-02 08:57:49 UTC
Setting the priority to Medium based on WA and impact.
Comment 21 Luigi Cantoni 2019-02-07 02:48:42 UTC
I have a similar problem with three motherboards. MSI H310M PRO-VD LGA1151 MSI B360M Gaming Plus DDR4 Turbo M2 LGA1151 Gigabyte Z370M-D3H LGA1151-CL The onboard motherboard video is what I am using. That thread is located at: https://forums.fedoraforum.org/showthread.php?320591-Fedora-29-onboard-video-memory-problem&goto=newpost I have tried the above ideas separately i915.enable_fbc=0, i915.enable_dc=0 and i915.disable_power_well=0 but problem still there. I am happy to try any other suggestions or debugs. I did not read all the pointers that the above points to just the main thread so if I missed something let me know and I'll try that too.
Comment 22 Lakshmi 2019-02-07 09:55:06 UTC
(In reply to Luigi Cantoni from comment #21) > I have a similar problem with three motherboards. > MSI H310M PRO-VD LGA1151 > MSI B360M Gaming Plus DDR4 Turbo M2 LGA1151 > Gigabyte Z370M-D3H LGA1151-CL > The onboard motherboard video is what I am using. > > That thread is located at: > https://forums.fedoraforum.org/showthread.php?320591-Fedora-29-onboard-video- > memory-problem&goto=newpost > > I have tried the above ideas separately > i915.enable_fbc=0, i915.enable_dc=0 and i915.disable_power_well=0 > but problem still there. > > I am happy to try any other suggestions or debugs. I did not read all the > pointers that the above points to just the main thread so if I missed > something let me know and I'll try that too. Is it GLK? Have you tried comment 18?
Comment 23 Geraud 2019-02-07 10:50:46 UTC
Hello everyone, just to share that I have the same issue using libreelec with a NUC7PJYH. It seems everybody using a GLK have the issue: https://forum.libreelec.tv/thread/12380-le-8-2-5-with-uhd-630-coffee-lake-gemini-lake-support-and-luks/?pageNo=10
Comment 24 Lakshmi 2019-02-07 13:25:11 UTC
(In reply to Geraud from comment #23) > Hello everyone, just to share that I have the same issue using libreelec > with a NUC7PJYH. > > It seems everybody using a GLK have the issue: > > https://forum.libreelec.tv/thread/12380-le-8-2-5-with-uhd-630-coffee-lake- > gemini-lake-support-and-luks/?pageNo=10 Can you confirm if the issue goes away after disabling fbc i915.enable_fbc=0 ?
Comment 25 Geraud 2019-02-07 13:45:38 UTC
Yes I did the test yesterday adding kernel parameter or driver config file...no luck the issue is still there.
Comment 26 Daniel Drake 2019-02-08 00:11:25 UTC
(In reply to Geraud from comment #25) > Yes I did the test yesterday adding kernel parameter or driver config > file...no luck the issue is still there. Can you double check that the parameter change took effect with the following command: > sudo cat /sys/module/i915/parameters/enable_fbc If it says "1" then you should open a new bug report as any screen corruption is not caused by fbc in that case. If it says "0" then something is wrong with the way you are setting the parameter.
Comment 27 Luigi Cantoni 2019-02-08 01:26:06 UTC
It appears I am not using glk as that is not in my dmesg/journal files. Thus I think I am not loading it. I just checked out comment#18 and that made no difference, same problem. I just tested again for i915.enable_fbc=0 Still there but using the check that Daniel suggested looks like it is going wrong. [root@test tmp]# dmesg | grep -i "kernel command" [ 0.116842] Kernel command line: BOOT_IMAGE=/vmlinuz-4.20.5-200.fc29.x86_64 root=/dev/sda3 ro resume=/dev/sda2 i915.enable_fbc=0 rhgb quiet LANG=en_AU.UTF-8 [root@test tmp]# cat /sys/module/i915/parameters/enable_fbc 0 I thought I was setting the parameter correctly but it appears I am not. Suggestion? I certainly hope that once set correctly it fixes it because then we will all be happier.
Comment 28 Daniel Drake 2019-02-08 02:58:02 UTC
Sorry, I got it the wrong way round in my last comment. What I meant to write: > sudo cat /sys/module/i915/parameters/enable_fbc If it says "0" then you have set the parameter correctly and you should open a new bug report as any screen corruption is not caused by fbc in that case. If it says "1" then something is wrong with the way you are setting the parameter. So, Luigi, you are setting the parameter correctly and it is not solving the issue. That means the issue you are facing is not the one being tracked here.
Comment 29 Luigi Cantoni 2019-02-08 03:40:07 UTC
Guess what. Looks like my problems is X11 related. When I tell X11 that it has an intel graphics device then my problem appears to go away. Two machines tested and MSI and a Gigabyte. I will be testing my third machine later (I have to wait until the users go to lunch). If I do not post anything more then it worked. If not I will provide more info. My fix is just to create up /etc/X11/xorg.conf.d/20-intel.conf and put Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection into it. Very simple and probably obvious in hindsight. As you suggest Daniel not exactly this problem.
Comment 30 Luigi Cantoni 2019-02-08 05:35:16 UTC
Now it gets confusing. It appears I was wrong my fix is not a fix. It depends on what order you do things and also a bit on what is on the graphical screen as to if you see it or not. The good bit is I appear now to have a method to make it fail etc (and sort of work). If I have ctrl-alt-F1 with the graphical login screen ctrl-alt-F2 is a logged in session ctrl-alt-F3 is the character based login. This is the screen display with the problem visible on it. Swap from F1<->F3 100% looks OK Swap F1<->F2 100% OK (always was and never had an issue) Swap F2<->F3 and my problem is there. Do F2->F3 (problem there) do F3->F1->F3 problem not there Or do F2->F1->F3 problem not there. It fixes up the display if I go through the F1 (graphical login) screen. I just re-tested my machines with my X11 conf file there and not there and the behaviour is as described above. The file makes no difference. I had not noticed that behaviour before as I normally go from F2-F3 and back again without going through F1. Also something I have noticed is that when I swap out of F2 for a moment the screen goes silly in the top left with the graphical data and F3 does not clear it but F1 seams to clear it out. My guess is the swap screen code is writing the data out (maybe only as temporary buffer) and F1 (as an initialisation code) clear that temporary area out) and that is what is happening and why F1 fixes it. Might have been helpful to know that.
Comment 31 Luigi Cantoni 2019-02-11 00:56:26 UTC
Hi All, I was not actually testing the Xorg version I now see. Using the login "gnome on Xorg" option I can see by the different display that I am using it and it makes no difference to the problem. The good thing I am fairly sure this is just a display issue and other memory is not getting damaged so should not cause anything really bad or strange to happen.
Comment 32 Luigi Cantoni 2019-02-11 01:49:34 UTC
Some more testing: with /etc/gdm/custom.conf having these lines in the daamon section [daemon] # Uncomment the line below to force the login screen to use Xorg #WaylandEnable=false WaylandEnable=true DefaultSession=gnome-xorg.desktop and selecting from the login cog either "gnome classic" or "gnome on xorg" it continues to fail. If you choose "gnome" (which I had not done before) it appears to be OK. Certainly the ways I was doing before to make it fail does not appear to fail.
Comment 33 Daniel Drake 2019-02-11 02:15:58 UTC
Luigi, please file a separate bug report for the problems you are facing. Since the issue you see is not related to fbc, it should be separated from this issue. Thanks.
Comment 34 Luigi Cantoni 2019-02-12 00:12:57 UTC
Separate bug now logged, thanks for all the help so far. 109610 xorg Driver/i i915 xorg display corruption on ctrl-alt-F3
Comment 35 Geraud 2019-03-05 20:21:26 UTC
(In reply to Daniel Drake from comment #26) > (In reply to Geraud from comment #25) > > Yes I did the test yesterday adding kernel parameter or driver config > > file...no luck the issue is still there. > > Can you double check that the parameter change took effect with the > following command: > > > sudo cat /sys/module/i915/parameters/enable_fbc > > If it says "1" then you should open a new bug report as any screen > corruption is not caused by fbc in that case. > > If it says "0" then something is wrong with the way you are setting the > parameter. OK I did the check tonight: I put the drivers option using echo "options i915 enable_fbc=0" >> /storage/.config/modprobe.d/i915.conf. I restarted and I did cat /sys/module/i915/parameters/enable_fbc with root account...the result is "1"... But still I'm a bit confused...if it is "1" shouldn't that mean that fbc is activated? Meaning the issue comes from fbc?
Comment 36 Lakshmi 2019-03-06 07:54:28 UTC
Daniel/Geraud, can you give your feedback with latest drmtip? I am not aware of any changes committed related to this specific bug. Still good to check with latest drmtip. (https://cgit.freedesktop.org/drm-tip).
Comment 37 firstname.lastname@example.org (Spammer; Account disabled) 2019-03-06 08:01:14 UTC
Comment 38 Geraud 2019-03-06 08:55:07 UTC
(In reply to Lakshmi from comment #36) > Daniel/Geraud, can you give your feedback with latest drmtip? I am not aware > of any changes committed related to this specific bug. Still good to check > with latest drmtip. > (https://cgit.freedesktop.org/drm-tip). Problem is on my side I'm both kind of a noob...and I'm using latest version of libreelec (https://libreelec.tv/) that is not a "regular" distribution with proper package management (like debian...)...so I really don't have any idea how to update this package... :-s
Comment 39 Geraud 2019-03-07 18:57:32 UTC
Hello, Just one question...as explained I don't know if I can help myself much more...but I guess I can share the issue on this forum to investigate deeper with the help of people who know how libreelec works and what can be tried: https://forum.libreelec.tv/thread/12380-le-8-2-5-with-uhd-630-coffee-lake-gemini-lake-support-and-luks/?pageNo=12 Hence, if somebody can first confirm me that when I run the command line: at /sys/module/i915/parameters/enable_fbc and get the result "1" it means that fbc is activated or not. Using this information I can then confirm that it is linked to fbc or not. If not it means that libreele is not taking into account the drivers options I created...so I can have a look on how I can force it to use it. If not then I can log a new bug report I guess...but at least it will be clear if my issue can be related to this bug or not.
Comment 40 James Ausmus 2019-03-08 19:51:38 UTC
Hi Geraud- If $ cat /sys/module/i915/parameters/enable_fbc gives you a 1, that means that the module parameter is set to allow FBC. However, this doesn't necessarily mean that FBC is active/enabled. To check this, you'll need to either look at a file in debugfs, or boot with the "drm.debug=0xe" parameter and check your kernel logs. To check the file in debugfs, do: $ mount | grep debugfs if this doesn't return results, then debugfs isn't mounted (or may not even be enabled in your kernel config) - you can choose to enable/mount debugfs if you choose - see https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt for some examples. If the mount command *did* return results, it probably looked something like: $ mount | grep debugfs debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) Then you can do: $ cat /sys/kernel/debug/dri/0/i915_fbc_status which will give you the "this moment right now" status of FBC. Alternatively, if you wan't to check via the kernel log, boot with the "drm.debug=0xe" kernel parameter, and then do: $ dmesg | grep -i fbc Which should give at least a few lines about FBC enabling and FBC status.
Comment 41 Geraud 2019-03-08 20:05:09 UTC
Hello James, Thank you very much. I did the mount | grep debugfs and then cat /sys/kernel/debug/dri/0/i915_fbc_status And the result is: FBC enabled Compressing: yes This means despites me creating the i985.conf file to set the driver parameters it didn't take it into account. I will try to ask on libreelec forum see if somebody has way to force the paramter. I don't want to add option to kernel boot as last time it kill the distribution for some reason. Good news is the bug is not
Comment 42 Geraud 2019-03-08 20:06:31 UTC
Sorry for my double reply...keyboard mistake... I was saying the good news is it doesn't seem to be new bug. It's the same fbc issue identified here. Thanks for the help guys. :-)
Comment 43 Geraud 2019-03-09 17:51:09 UTC
OK so after checking on libreelec forum the only way with libreelec to solve the issue is to add the option to one of those three file (depending on your installation: /flash/EFI/BOOT/syslinux.cfg, /flash/syslinux.cfg or /flash/extlinux.cfg Just before "quiet". This fix works fine but creating the i915.conf doesn't work with this specific distribution. So I can confirm that the bug we experienced with libreelec is linked to fbc...and the workaround to disable the function untill the bug is fixed. Thanks a lot for your help guys. :-)
Comment 44 Lionel Landwerlin 2019-03-11 16:18:19 UTC
*** Bug 109950 has been marked as a duplicate of this bug. ***
Comment 45 Arek Hiler 2019-04-05 04:35:10 UTC
Seems to be relevant: https://patchwork.freedesktop.org/series/58843/
Comment 46 Daniel Drake 2019-04-12 07:01:58 UTC
I tested Linux 5.0, 5.1, next-20190411, and drm-tip-2019y-04m-12d-06h-24m-37s. All those versions continue to be affected by the bug, trivially reproduced in the gdm login manager. I also tested applying the above mentioned patch "drm/i915: FBC needs vblank before enable / disable" to all those kernel versions. They all reproduced the graphical corruption at the top of the screen exactly as before. It's now been over 6 months since this bug was reported. Please let me know how we can help further.
Comment 47 Sanjeev 2019-04-19 14:46:57 UTC
still exist on new kernels, currently running kernel version 5.0.7, my unit is asus e203mah, AFAIK current workaround (disabling fbc,ie., enable_fbc=0) makes it disappear
Comment 48 Tom Seewald 2019-04-19 21:14:47 UTC
Could frame buffer compression at least be disabled by default on GLK until this issue can be looked at?
Comment 49 Lakshmi 2019-04-23 07:51:42 UTC
(In reply to Daniel Drake from comment #46) > I tested Linux 5.0, 5.1, next-20190411, and > drm-tip-2019y-04m-12d-06h-24m-37s. > > All those versions continue to be affected by the bug, trivially reproduced > in the gdm login manager. > > I also tested applying the above mentioned patch "drm/i915: FBC needs vblank > before enable / disable" to all those kernel versions. They all reproduced > the graphical corruption at the top of the screen exactly as before. > > It's now been over 6 months since this bug was reported. Please let me know > how we can help further. @Daniel, Have you tried the workaround mentioned in Comment 47? @James, any advice here?
Comment 50 Daniel Drake 2019-04-23 08:01:02 UTC
(In reply to Lakshmi from comment #49) > @Daniel, Have you tried the workaround mentioned in Comment 47? Yes! That workaround was found over 6 months ago (Comment 11) and has been verified to be effective by myself and several other people in the comments above.
Comment 51 Tom Seewald 2019-05-06 17:37:04 UTC
Looks like there was a patch posted to disable fbc on GLK but it appears that it is not going to be accepted upstream.  https://lists.freedesktop.org/archives/intel-gfx/2019-April/196619.html
Comment 52 Jani Nikula 2019-05-09 12:32:22 UTC
We need to get FBC working on GLK too, but in the mean time pushed commit 1d25724b41fad7eeb2c3058a5c8190d6ece73e08 Author: Daniel Drake <email@example.com> Date: Tue Apr 23 17:28:10 2019 +0800 drm/i915/fbc: disable framebuffer compression on GeminiLake
Comment 53 Lakshmi 2019-07-19 11:58:06 UTC
Is this bug should be open till FBC working on GLK? or We can close this bug?
Comment 54 You-Sheng Yang [:vicamo] 2019-08-15 07:20:32 UTC
It seems this also happens to some IceLake platforms, a horizontal line of display corruption appears every time logging in via gdm. With s/IS_GEMINILAKE/IS_ICELAKE/ to the landed commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=396dd8143bdd94bd1c358a228a631c8c895a1126 , this problem is gone.
Comment 55 Lakshmi 2019-08-16 11:21:39 UTC
(In reply to You-Sheng Yang [:vicamo] from comment #54) > It seems this also happens to some IceLake platforms, a horizontal line of > display corruption appears every time logging in via gdm. With > s/IS_GEMINILAKE/IS_ICELAKE/ to the landed commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=396dd8143bdd94bd1c358a228a631c8c895a1126 , this problem is gone. Can I close this bug?
Comment 56 Daniel Drake 2019-08-19 02:56:32 UTC
I'd suggest leaving this bug open til fbc is fixed on Gemini Lake. And given that it is reported to affect Icelake too that sounds like an even stronger reason to leave this open.
Comment 57 Lakshmi 2019-08-20 06:59:15 UTC
(In reply to You-Sheng Yang [:vicamo] from comment #54) > It seems this also happens to some IceLake platforms, a horizontal line of > display corruption appears every time logging in via gdm. With > s/IS_GEMINILAKE/IS_ICELAKE/ to the landed commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=396dd8143bdd94bd1c358a228a631c8c895a1126 , this problem is gone. (In reply to Daniel Drake from comment #56) > I'd suggest leaving this bug open til fbc is fixed on Gemini Lake. > And given that it is reported to affect Icelake too that sounds like an even > stronger reason to leave this open. Currently this issue affects only GLK. If there is any issue on Icelake, I would recommend to create a new issue to investigate the issue separately.
Comment 58 You-Sheng Yang [:vicamo] 2019-08-26 04:07:38 UTC
Created a new issue for IceLake in https://bugs.freedesktop.org/show_bug.cgi?id=111484
Comment 59 Martin Peres 2019-11-29 17:52:57 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/162.