Created attachment 1160034 [details] Xorg.0.log - shows seg fault, though I I am using the GUI Description of problem: On a fresh install of Fedora 24 BETA using a nuc6i7kyk w/ Iris Pro 850 integrated graphics I am getting intermittent graphics glitches/artifacts on the second monitor in a displayport MST daisychain. I have had one hang of the system after letting it go to the idle/lock screen which many be related. I am not doing anything special, just SSH and web. General setup of a new system, installing packages. Version-Release number of selected component (if applicable): How reproducible: So far this is happening consistently through several reboots. Steps to Reproduce: 1. Use default GUI and They will crop up. 2. 3. Actual results: intermittent glitch/artfact Expected results: smooth graphics Additional info: Please let me know what other troubleshooting information I can provide. I know everything I am using is brand new so I am happy to be a test case. I am thrilled that the Daisy chaining of DP is working in this setup, that was not happening on F23!
Glitches: second screen - image will twitch and appear broken monetarily both screens - intermittent freezing where mouse cursor is unmovable and system is unresponsive. This happened most recently while loading a large webpage (My Oracle Support, after login) System Hangs: Once, so far, after system idle timeout system was completely unresponsive. No keyboard input, no ctrl-alt-F2. I resorted to holding down the power button. I have not let the system go idle since to retest.
Hi, We're still working hard on making DP MST setups like yours work reliably, we're getting there, but obviously we are not there yet. These things are mostly a kernel issue can you try upgrading to 4.6? You can find it here: http://koji.fedoraproject.org/koji/buildinfo?buildID=765346 Download the -core and -module x86_64.rpm files, and then in a dir with both of them do: sudo rpm -ivh kernel*.rpm And then reboot into the new kernel. Also what does rpm -q xorg-x11-drv-intel say ? If you're not at 2.99.917-23.20160512.fc24 please give that a try as well (should be a matter of "dnf update xorg*"). If all this does not help, there are a number of fixes queued up for 4.7 as well, once 4.7-rc1 is out you could go here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 And give 4.7-rc1 a try, note the rc0-s you are currently seeing there do not yet have the changes, rc1 should have them. Regards, Hans
Just also read your hang after idle problem, that sounds a lot like a bug which is fixed by making sure you've the latest xorg-x11-drv-intel, as mentioned above.
Thank you Hans, I'll run through those tests and report back.
# rpm -q xorg-x11-drv-intel xorg-x11-drv-intel-2.99.917-22.20160119.fc24.x86_64 # dnf update xorg* . . . # rpm -q xorg-x11-drv-intel xorg-x11-drv-intel-2.99.917-23.20160512.fc24.x86_64
Up and running on the new kernel. I'll keep using it for the day and update: $ uname -a Linux ---.---.net 4.6.0-1.fc25.x86_64 #1 SMP Mon May 16 14:57:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
* The visual artifacts are still occurring, I have seen them on both monitors in the MST chain now. * I have not been able to replicate the lock screen freeze after updating. I did a full 'dnf update'. I had not done that since installing from the live image. * Staying on Kernel 4.6. Anyway, I am content having let you know the issue since I know this is all beta software. I will keep an eye out for updates and stay current. You are welcome to close this ticket or leave it open. Either way feel free to reach out to me if I can be of some help in testing. Thanks!
(In reply to contact from comment #7) > You are welcome to close this ticket or leave it open. It is best to keep this open, both for tracking purposes and so that if other people have a similar problem they can find it easily. > Either way feel free to reach out to me if I can be of some help in testing. As said before if you can take a peek at: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 occasionally and give 4.7-rc1 (or newer) a try when it becomes available that would be great.
$ uname -a Linux xxx.yyy.zzz 4.7.0-0.rc1.git3.1.fc25.x86_64 #1 SMP Thu Jun 2 15:45:29 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I fired up the 4.7 release candidate this morning for testing. I do still have artifacting going on. Again it mostly seems to be on the second monitor in the MST chain, but I wouldn't promise it just yet. Subjectively I would say that I see it less than in the 4.6 kernel. Using the 4.6 kernel I see it much less than with 4.5 I have also done some shuffling of displayport cables in this setup to make sure I didn't have a bad one in there somewhere. The behavior is the same in all combinations of cables. I see there is a 4.7.git4 kernel in the works now, I will keep pulling the newer ones to try out as I see them.
Hi, (In reply to contact from comment #9) > $ uname -a > Linux xxx.yyy.zzz 4.7.0-0.rc1.git3.1.fc25.x86_64 #1 SMP Thu Jun 2 15:45:29 > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > > I fired up the 4.7 release candidate this morning for testing. > > I do still have artifacting going on. Again it mostly seems to be on the > second monitor in the MST chain, but I wouldn't promise it just yet. > > Subjectively I would say that I see it less than in the 4.6 kernel. Using > the 4.6 kernel I see it much less than with 4.5 > > I have also done some shuffling of displayport cables in this setup to make > sure I didn't have a bad one in there somewhere. The behavior is the same in > all combinations of cables. > > I see there is a 4.7.git4 kernel in the works now, I will keep pulling the > newer ones to try out as I see them. Thanks for the testing, but 4.7 does not contain the patches I was hoping it would, I've been testing intel-drm-next myself which does (finally) contain the displayport watermark fix patches I was expecting to be in 4.7 already. Since these patches are quite invasive they likely will not get backported. So you'll have to wait for 4.8-rc1 to get these patches, which will hopefully fix the flickering issue. Regards, Hans
Hi, Given the many issues with skylake support which are (hopefully) fixed by the patchset discussed in the bug, I've backported the patchset to 4.6, which should become available as a Fedora update in the next weeks. In the mean time you can grab a test-build with the patches here: https://fedorapeople.org/~jwrdegoede/kernel-4.6.2-300-bz1305038/ Download the kernel-core and kernel-modules packages from there and then in a dir with those 2 files do: rpm -ivh kernel*.rpm And then reboot, and do "uname -a" to check that you're running the new kernel. Hopefully this will fix your problems. Regards, Hans
> uname -a Linux 4.6.2-300.fc24.x86_64 #1 SMP Mon Jun 20 15:40:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Thanks Hans! I just fired this up and I'll report back after I have used it for a bit.
Looks like these are still happening. I am getting the glitches showing up on both monitors while using the new kernel. I did a dnf update for good measure and rebooted. > uname -a Linux 4.6.2-300.fc24.x86_64 #1 SMP Mon Jun 20 15:40:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
(In reply to contact from comment #13) > Looks like these are still happening. I am getting the glitches showing up > on both monitors while using the new kernel. That's too bad I was really hoping this patch-set: http://www.spinics.net/lists/intel-gfx/msg95595.html Which is in the kernel you tested would fix this, to be clear I was specifically expecting this to fix the "second screen - image will twitch and appear broken monetarily" thingie, the cursor freeze is likely caused by a gpu freeze which is not a kernel issue, but rather a mesa issue.
Yup, I was referring to the twitching and brokenness. The mouse freezing and lock screen issues haven't happened since I updated the x11 drivers the day I opened the ticket.
Hi! Sorry it's taken me a little bit to get to this, work has been busy. So, there's a couple of pieces of information I need from you: - The exact models of both the monitors - The model information for the laptop (just incase I can't reproduce these issues on any of my systems here) - What brand/model of MST hub you're using to daisy-chain the two monitors - The dmesg from your machine when you start experiencing these issues For the dmesg, you'll need to make sure you boot your kernel with drm.debug=0x6 added to the kernel commandline, so that I can see all of the debug information I need in your kernel log. Let me know if you need help with getting any of these things
Thanks Lyude, Monitors are both Dell U2414Hb Computer is the Intel nuc6i7kyk, running from the mini displayport The monitors themselves do MST so there is no additional hub I will get the dmesg info as soon as I can. I just did another dnf update last night (2016-06-22) and I notices some Xll packages. I just rebooted and I am sort of hoping the problem goes away. If not I will reboot with the drm.debug kernel parameter.
Created attachment 1171774 [details] Requested dmesg output in a few text files tar'd together
No such luck on the problem just going away. I just attached a tar file with some dmesg output. If you have a slicker way you would like me to get that dmesg output let me know and I'll upload more.
> Monitors are both Dell U2414Hb > Computer is the Intel nuc6i7kyk, running from the mini displayport > The monitors themselves do MST so there is no additional hub We meet again Dell U2414Hb… This monitor is very notorious for being responsible for breaking a lot of systems, and this definitely isn't the first time we've had to research bug fixes for this. Luckily it's problematic enough I even have one at my desk to test :). > If you have a slicker way you would like me to get that dmesg output let me > know and I'll upload more. In the future, the easiest way to get the entire dmesg log in one go: journalctl --dmesg --lines=10000 -b -e
Ah whoops, I forgot to ask: Would you be able to get me the dmesg output using that method instead? It would be a lot easier to look through
Yes, I will get that to you as soon as I get home to that machine. SSH is not responding at the moment.
Actually don't worry about it. I played around at the office and managed to reproduce your bug. The MST displays don't seem to always connect, and when they do there's definitely a visible flickering. It looks like the problem is indeed some watermark calculation problems Intel still hasn't fixed yet. I'm going to be going on PTO after Wednesday so you might not see much activity on this until I get back next Monday.
Created attachment 1173198 [details] dmesg all content
I went ahead and attached it anyway, just in case that is of some use. I didn't have any luck with the MST on these until I installed the Fedora 24 beta. Fedora 23 didn't cooperate with them at all. I was reading up on all the woes people have had with these monitors so I wasn't expecting much when I got the 24 live image, but they lit right up! Thanks for taking this on, I hope your PTO is something fun!
Just to let you know, we haven't gotten the watermark issues fixed yet but I've at least managed to fix the hangs that are coming from the pipe underruns: https://lkml.org/lkml/2016/7/11/731
Sorry for being quiet last week, this bug ended up being pretty painful to track down. However I managed to figure out the issue and submit some patches for it. They're on track to be included in the F24 kernel, but until then I've fired up a koji build with the required patch added. Once the koji build finishes you'll be able to download the kernel RPMs from here: http://koji.fedoraproject.org/koji/taskinfo?taskID=14935231 Let me know whether or not this fixes your issues.
Whoops, please ignore the previous koji link, I ran that build against the upstream kernel version by accident. Here's the proper koji build to grab the RPMs from: http://koji.fedoraproject.org/koji/taskinfo?taskID=14935269
Thanks! I will verify this today when I get home and update the ticket.
Don't worry about updating the ticket just yet, I can handle that. Also just adding an extra warning: there might be problems with that fix so be wary.
I just got this booted up: > uname -a Linux ---- 4.6.4-301.LyudeSklCursorFlickerFix1.fc24.x86_64 #1 SMP Mon Jul 18 17:20:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux So far, after a few minutes I am not seeing any of the issues I was having before. I am cautiously optimistic. I'll keep running and and I will be working on this machine all day Friday so that will be the big test. I will attach dmesg output with drm trace enabled.
Created attachment 1181328 [details] dmesg output with latest kernel fix in place
OK, I just got a few of these artifacts at Jul 18 15:58:02. I am attaching a new dmesg from that time.
Created attachment 1181329 [details] dmesg output 4.6.4-301.LyudeSklCursorFlickerFix1.fc24.x86_64 after flickering
Alright, so as it turns out my previous fix was entirely wrong, whoops. I should have a real fix that's working now locally, so I'll update this again once I've got the patches submitted and a koji build going
Alright, wrote up a lot of patches that should entirely fix this issue upstream: https://patchwork.freedesktop.org/series/10108/ I haven't gotten a koji build setup yet since I'm pretty sure we might need a few additional patches from 4.7. I'll link to a build here once I make one tomorrow morning at work.
Great, thanks! I'll get it installed when the build is done and put it through its paces on Friday.
Alright, this *should* just fix your issues with all of the flickering. On the X1 carbon I tried this with I wasn't able to get any pipe underruns or screen flickers, so let's cross our fingers. http://koji.fedoraproject.org/koji/taskinfo?taskID=14971690
I do not seem to be having the same experience with this one. I still see some flickers and now I am getting a trail of mouse cursors on the second monitor. User experience is definitely worse than before. I will upload a picture (screenshot did not capture the cursor trail) and dmesg. I see some other strangeness with highlighting text on the terminal not being a solid color and things just behaving strangely as the mouse cursor moves over them. As I type this up there are several cursors dancing around on the second monitor. I will throw some extra details here in case I have just missed any steps that I should have done. Please let me know if I've missed anything or done anything silly. > uname -a Linux porter.ericbisme.net 4.6.4-301.LyudeSklCursorFlickerFix3.fc24.x86_64 #1 SMP Thu Jul 21 21:58:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I grabbed the following from your build and installed with dnf: kernel-core-4.6.4-301.LyudeSklCursorFlickerFix3.fc24.x86_64.rpm kernel-modules-4.6.4-301.LyudeSklCursorFlickerFix3.fc24.x86_64.rpm kernel-modules-extra-4.6.4-301.LyudeSklCursorFlickerFix3.fc24.x86_64.rpm
Created attachment 1182686 [details] dmesg output
Created attachment 1182687 [details] picture of monitor showing a trail of mouse cursors
after sending that I also installed the package: kernel-4.6.4-301.LyudeSklCursorFlickerFix3.fc24.x86_64.rpm, but I see the same behavior.
installed all packages, same behavior
(In reply to contact from comment #43) > installed all packages, same behavior Alright, I probably missed some patches when I made the spec file for the kernel RPM (I tested the patches against fedora's git kernel tree, not the rpm, so I suppose some patch might have been included there that wasn't in the kernel rpm for some reason...). I'll check the RPM out here and see what happened and update you when I've figured it out.
Thanks! I appreciate all the time you are spending on this and I'll test the new build as soon as it is ready.
Mind giving this one a try? Tried the RPM on my machine over here and it seems to fix the issue mostly. https://koji.fedoraproject.org/koji/taskinfo?taskID=15014805
Thanks! I will try it out today after work.
I'm still getting it > uname -a Linux xxxxxx 4.6.4-301.LyudeSklCursorFlickerFix4.fc24.x86_64 #1 SMP Mon Jul 25 18:38:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I will attach the latest dmseg log. I installed the following using dnf, let me know if I need more of the packages kernel-4.6.4-301.LyudeSklCursorFlickerFix4.fc24.x86_64.rpm kernel-core-4.6.4-301.LyudeSklCursorFlickerFix4.fc24.x86_64.rpm kernel-modules-4.6.4-301.LyudeSklCursorFlickerFix4.fc24.x86_64.rpm I hope I am not screwing something up here to break my testing!
Created attachment 1184399 [details] latest dmesg with trace on
Just to clarify. I am NOT getting the mouse cursor trails, that is cleared up. I am just getting the flicker. I have only had it up for 10 minutes or so, but I believe I have only seen them on the second monitor in the chain and it took a bit longer to happen than usual.
It may very well be we need even *more* fixes. I'm really sorry how many tries this is taking, this is something that should have been fixed months ago. I'll give you another koji build when I've got one. In the mean time: I do know that patchset had one bug with a patch I had written for SAGV support (tldr thing we can use to prevent underruns) that would require you connect the displays after booting for it to work properly. I would give that a try
Alright, so I've got pretty high hopes for this build once it finishes: http://koji.fedoraproject.org/koji/taskinfo?taskID=15179235 If you still experience flickering, try adding i915.enable_sagv=0 to your kernel parameters and see if the flickering still occurs. Let me know the results, along with whether or not you needed to use i915.enable_sagv=0.
thanks! I'll keep an eye on the build and boot it when it completes.
Created attachment 1188993 [details] dmesg output
Created attachment 1188994 [details] dmesg output
The bearer of bad news returns :-( I am still seeing some of the same artifacts. With or without: i915.enable_sagv=0 I attached relevant dmesg output which still has the trace enabled.
I installed these 3 packages: kernel-4.6.5-300.LyudeSklAtomicWmUpdating3.fc24.x86_64.rpm kernel-core-4.6.5-300.LyudeSklAtomicWmUpdating3.fc24.x86_64.rpm kernel-modules-4.6.5-300.LyudeSklAtomicWmUpdating3.fc24.x86_64.rpm
Just to make sure: when you are talking about screen artifacts, are you talking about your displays flickering?
I would say there are two different manifestations. In one case the display will flicker, turn off briefly and then back on. In the other case the image on the monitor breaks/glitches/twitches momentarily. It doesn't go dark just jumps around. I could get a video this evening if that would be helpful to make sure we're working off the same definition.
I'm praying this is a case of some other patch we need that isn't in the backport, so I'm going to get a koji build going of a later kernel version with these patches added. Be warned: this is a rawhide kernel, so the only thing I'd test for stability on this is whether or not the display flickers. http://koji.fedoraproject.org/koji/taskinfo?taskID=15189193 Same testing stuff, try with i915.enable_sagv=0 if you have problems and just for laughs, try i915.enable_sagv=1 as well.
Also yes, a video would be helpful if possible
Could this be psr, I would expect psr to only be used with eDP ports, but maybe it is used with external DP under some conditions too and/or the DP port gets misidentified as a eDP (this is a NUC afterall, so a mobile chipset). This is likely a long shot, but can you try booting with i915.enable_psr=0 on the commandline ?
I'm also extremely suspicious of the MST display you seem to be using. There were definitely issues with i915 not updating watermarks correctly before, but flickering without any underruns appearing in the log very well might be another issue. Sorry to bug for so much information, but if possible could you also see if you could find a similar configuration that doesn't use MST and see whether or not that makes a difference?
https://www.dropbox.com/s/haaru3ewzawntlf/videos.20160810.tgz?dl=0 That file at dropbox has two videos showing examples of the glitch. They are both short and the glitch is toward the end of each.
I will catch up on these other options shortly.
I just ordered a thunderbolt 3 to displayport adapter. I will test with the monitors running from separate outputs. Is it those Dell monitors that are the source of the suspicion? I know they have a questionable MST reputation.
I removed the trace and sagv options and put in i915.enable_psr=0. I still see some of the artifacting. I will work through the new kernel and various settings today as I get a chance.
It looks like the build of the 4.8 kernel bombed
Sorry for taking so long to reply. Getting these patches completely working and upstream took *WAY* longer then expected (and we've still got one patch waiting to get pushed ): SO: I temporarily switched my main work machine to a Skylake laptop (T460p, nvidia card disabled) so that I could actually run this myself and catch any possible problems with it that I might not notice otherwise. So far I haven't run into any underruns or any flickering of any kind (both in a single display configuration, and triple display configuration). If this doesn't fix your problem then I'm confident something else has to be wrong with your system: https://koji.fedoraproject.org/koji/taskinfo?taskID=15431468
(In reply to Lyude from comment #69) > Sorry for taking so long to reply. Getting these patches completely working > and upstream took *WAY* longer then expected (and we've still got one patch > waiting to get pushed ): > > SO: I temporarily switched my main work machine to a Skylake laptop (T460p, > nvidia card disabled) so that I could actually run this myself and catch any > possible problems with it that I might not notice otherwise. So far I > haven't run into any underruns or any flickering of any kind (both in a > single display configuration, and triple display configuration). If this > doesn't fix your problem then I'm confident something else has to be wrong > with your system: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=15431468 (I should note by "something wrong" I mean a different bug in i915, not a hardware issue)
Great, I will test this tonight. I should have also added. I did get a thunderbolt 3 to display port adapter so I have been running the monitors from separate ports to test. I have still seen some flickering on the displayport monitor, but I have not noticed it on the one running from the thunderbolt port. I will go back to the original MST setup to test this latest kernel and report back.
(In reply to contact from comment #71) > Great, I will test this tonight. > > I should have also added. I did get a thunderbolt 3 to display port adapter > so I have been running the monitors from separate ports to test. I have > still seen some flickering on the displayport monitor, but I have not > noticed it on the one running from the thunderbolt port. > > I will go back to the original MST setup to test this latest kernel and > report back. Alright, if in doubt try with the thunderbolt adapter as well or preferably just plug the displays directly in if possible. Displays flickering on an adapter is definitely another driver issue that needs to be addressed, but separately from this one.
So I do still get the same behavior when using the original MST setup with the two monitors. This machine only has one displayport out so I can't plug both in individually. For grins I also ran MST through the thunderbolt adapter. same behavior I am back to running one display via thunderbolt and one via DP as that is the most consistent setup. In that config I have no artifacts on the thunderbolt monitor, but the DP monitor still shows them. I am heading out of town for a week, but if you have some more experiments for me I will run through them as soon as I am back.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 24 has now been rebased to 4.7.4-200.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.