Hi all I own an Intel NUC5i7RYH linked to 3 monitors (1 on HDMI and two on the display port using a splitter) The cpu is an i7-5557U with Iris Graphics 6100. Till 3 week ago (older fedora provided mesa driver) I was using the SNA driver without any issues till the update of the mesa and kernel. Now the SNA is unusable, under SNA some monitors are not drawed at all for hours (the login progress bar stays also after the login is completed and neither the mouse shows) but sometimes (at random) it remember to update the screen and it shows that it should appear there... And most of software (like firefox) shows massive graphics corruptions. So I switched to UXA and as a result the performance dropped so much that a video played on youtube make the machine unusable and any kde animation is choppy! Distribution Fedora 22 Hardware: NUC5i7RYH Kernel: 4.2.3-200.fc22.x86_64 X.Org X Server 1.17.2 GLX version: 1.4 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.9 (git-8957b69) OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 10.6.9 (git-8957b69) OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.9 (git-8957b69) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 libdrm 2.4.61
Reassigning to the 2D driver.. As a temporary measure, you could try AccelMethod "blt" instead of UXA.
Start with attaching a good Xorg.0.log (if you still have the driver from ~3 weeks ago) and today's broken Xorg.0.log. Then see which kernels you still have available, if you know which you had ~3 weeks ago, retest with that.
Due to a very busy week for I can only attach the current UXA log, This week-end I'll try to make all the test (I'll check dnf log for previous version of the x.org driver)
Created attachment 119091 [details] Xorg log UXA buggy driver Xorg log UXA buggy driver
I've discovered that the issue is related to the kernel version not the driver itself (both updated at the same day according to the dnf log) With kernel 4.2.3 I have all the issues I've reported while with kernel 4.1.10 everything seems to work fine (but I'll make some more tests). I'll attach both logs.
Created attachment 119166 [details] log that shows with kernel 4.2.3 (buggy one)
Created attachment 119167 [details] log that shows with kernel 4.1.10 (good one)
Kirys, can you bisect the issue?
What should I do?
(In reply to Kirys from comment #9) > What should I do? The idea is to find the kernel commit between v4.1 and v4.2 that introduced the regression (unless Chris has some better ideas at this point). https://fedoraproject.org/wiki/User:Ignatenkobrain/Kernel/Bisection https://wiki.ubuntu.com/Kernel/KernelBisection
well that's a lot of work ^_^' The nuc is my home pc so is not something I can do during my work days, I'll try during weekends but it seems this will take a lot of time.
(In reply to Kirys from comment #11) > well that's a lot of work ^_^' > > The nuc is my home pc so is not something I can do during my work days, I'll > try during weekends but it seems this will take a lot of time. It means roughly 13 kernel build, install, test cycles. You should probably try 'make localmodconfig' instead of using distro kernel config to minimize the build time.
Oh, and while Chris is known to have pulled rabbits out of his hat, bisecting may yet be the fastest way to find out what's going on.
understood, I'll try to do it. Even thought I've build "my kernel" before (due to a previous issue with intel driver many years ago aka bug 43709) first time I'll do this kind of work. I'll follow the articles, but I can work on this only when I'm home so it'll take some time. Bye K.
the bisect tutorial (https://fedoraproject.org/wiki/User:Ignatenkobrain/Kernel/Bisection) for fedora doesn't seems to work on fedora 22 :( http://forums.fedoraforum.org/showthread.php?t=307260 I'll try a "manual approach" Cya F.
Bug scrub: Reassigned to reporter to check
As i said i was unable to follow the tutorial, and this is a really busy period for me. I'll try to do this in the first week-end of december.
Lowering the priority. This is not blocking our work and we haven't been able to reproduce the problem on our side.
Elio, Can you reproduce it and provide details? Thanks
Today I've updated (by mistake ^_^) to 4.2.6-200 and the problem seems to be reduced. The massive corruption is gone, but there still random lock of updates on some monitors (I've 3 monitors connected to the pc) that happen always at login and seldom after it. The lock disapears if I go to text console (ctrl+alt+f2-6) and came back to the graphical one. Home to make more test soon. Cya K
Currently screen update lockup is worse than a month ago. This is not only Skylake, but on most Intel cards. Confirmed on 965GM. A little detail: This is mostly triggered by Qt and KDE. In my case KDE+SDDM is frequently triggering this bug. Also see https://bugs.freedesktop.org/show_bug.cgi?id=92505 for some hints.
(In reply to Tatsuyuki Ishi from comment #21) > Currently screen update lockup is worse than a month ago. This is not only > Skylake, but on most Intel cards. Confirmed on 965GM. Please file new bugs on unrelated issues.
Timeout, closing. I'll presume we've fixed this. Please reopen if the problem persists with latest kernels.
Base Kernel from clean enviroment 4.04-301.fc22 After normal update, going to 4.4.14. No issues so far with 3 monitors, one by MST through DP dongle.
So closed.
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.