Created attachment 125794 [details] Journal log with kernel 4.7-1 using intel driver I have a desktop machine (Intel Ivybridge DQ77KB ) and running Arch linux. After update to kernel 4.7.0-1 with the usual pacman -Syu my desktop initially boots up fine and presents the sddm greeter screen as normal - but when logging in the usual splash screen appears on the monitor with the progress bar moving across, but at around 90% through this process, the plasma login seems hangs for many seconds - eventually the splash screen disappears and I end up with just the desktop background image - but no taskbar, and the mouse becomes active again after being unavailable whilst the progress bar and splash are on the screen. Once the mouse is active again and I can select the usual options with right click including the logout option. Rebooting makes no difference, and logging out and back in also makes no difference. Downgrading the kernel back to 4.6.4-1-ARCH allows my plasma desktop to login normally again - so this looks like a possible bug in the 4.7 kernel Intel driver. I ran some more tests. If I update to kernel 4.7-1, and then remove the xf86-video-intel package and remove the file /etc/X11/xorg.conf.d/20-intel.conf so that the system uses the modesetting driver instead of the intel driver then the system boots to a normal graphical sddm login screen and logging in completes to give a normal plasma desktop including the taskbar. However the Kickoff menu opens in a strange way with it seems items off the left of the screen so that they are not accessible. Also if I start the chrome browser it appears to start but is not on the screen - again possibly it is trying to place the chrome window outside of the screen area. So although the graphics partly works it is not usable. The versions of key packages are: xorg-server 1.18.4-1 (xorg) xf86-video-intel 1:2.99.917+691+ga77397a-1 (xorg-drivers xorg)
Created attachment 125795 [details] Xorg log file using kernel 4.7-1 and Intel driver
Created attachment 125796 [details] Journal log with kernel 4.7-1 using modsetting driver
Created attachment 125797 [details] Xorg log with kernel 4.7 using modesetting driver
Created attachment 125798 [details] Journal log using kernel 4.6.4-1 and Intel driver
Created attachment 125799 [details] Xorg log file using kernel 4.6.4-1 and Intel driver
I have also tried setting Option "DRI" "2" in the xorg config files but that does not make any difference when running kernel 4.7-1
$ lspci -v | egrep VGA 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
This problem remains the same with kernel 4.7.1-1
The problem remains with plasma-framework (5.24.0-1 -> 5.25.0-1)
Same issue here on the latest arch linux (plasma 5.25.0-1), but on a different GPU driver: Gallium 0.4 on AMD TONGA (DRM 3.3.0 / 4.8.0-rc2-mainline, LLVM 3.8.1) The issue also persist on 4.7.1 kernel and even in the 4.8rc2 kernel. For me after the kwin_x11 fails to start during the loading of the desktop environment, a popup appears, that kwin failed too many times and if I wish to try other window manager (kwin_x11 and openbox are in the dropdown menu). If I chose openbox, the desktop will drop into a openbox session and works as it should.
Is it possible that a change in the kernel between 4.6 and 4.7 has caused a problem in the plasma desktop code to visibly emerge? With the plasma desktop it is possible that code in the separate sets of packages (plasma and frameworks) may have bugs in it that only show up when the kernel drivers change in a particular way? How can we get diagnostics to get data which will point to where the bug originates?
The problem remains with the update for xf86-video-intel (1:2.99.917+691+ga77397a-1 -> 1:2.99.917+697+g12c14de-1)
Created attachment 126017 [details] Journal log with debug parameters on kernel boot line I ran a test with both drm.debug=0xe and i915.semaphores=1 with kernel 4.7 booted - this also fails to complete the plasma login, and this file is the journal following the boot.
I tried something new today with this - after updating and booting the 4.7 kernel and entering the login details to the sddm greeter, the usual hang time with the splash image on the screen eventually times out and gives just a desktop background image - at that point I used right click to unlock the widgets on the desktop, and added a new default panel which displays and works correctly. If at that point I logout and then log back in, then the splash screen hangs for the same extended period, and when it disappears the panel that I added after the previous login is no longer displayed, and again just a desktop background image is on the screen. However, if I then log out using right click and selecting to leave plasma, and downgrade the kernel back to 4.6 which was previously working, and log back in to plasma, which works successfully again, then the login does show the new panel that I added when I had booted kernel 4.7 - which I can then remove and the original panel is there and working as normal! I don't know therefore if this might point to a bug in plasma workspace or kwin that has surfaced with the current version of the kernel 4.7, and which might be fixed in newer versions of plasma, or when plasma 5.8 is released?
The bug remains the same with kernel 4.7.2-1
Also reported at: https://bugs.kde.org/show_bug.cgi?id=367822
I find the problem on my system (Archlinux), it was caused by the package gcr. It contains a config file /etc/security/limits.d/10-gcr.conf, which set a hard memory limit to 1GB for all users, and killed kwin_x11 each time it tried to use the memory. I noticed it when I tried to run dota2 while had drm.debug=0xe as boot parameter (maybe no relation with the boot parameter - not sure): "kernel: mmap: dota2 (4025): VmData 1074675712 exceed data ulimit 1073741824. Update limits or use boot option ignore_rlimit_data."
@partizann I think your issue must be different to mine - I have gcr installed and see the same in the config file, but don't have the kernel mmap line in my log files even with the debug turned on, but as per the comment in the kde bug report at: https://bugs.kde.org/show_bug.cgi?id=367822#c4 it seems that there was a bug that seems to be fixed in the frameworks package set, so I am now waiting for the patched version to come through to archlinux repos to test on my system - though it looks like it will be a couple of weeks before the next release of plasma frameworks in mid-September and I should then be able to test whether this fixes the issue I originally reported in this bug report.
After the update to plasma frameworks 5.26.0-1 I am still unable to login with any kernel beyond 4.6.4-1 so this issue is not fixed for me. My plasma package set is 5.7.5-1. This is on my Ivybridge machine though I have two Haswell machines which are fine and don't exhibit this problem.
Perhaps I should rephrase the comment - the login does complete but there is no panel.
Mike - We seem to have neglected the bug quite a bit, apologies. Do you see this problem with the latest kernel (preferable drm-tip branch from git://anongit.freedesktop.org/drm-tip) + intel-driver ? Mark this as REOPENED if you can reproduce (and attach kernel log) and RESOLVED if you cannot reproduce.
My apologies for not adding a comment a long time ago and marking this as resolved. It turned out that the issue was that some of the plasma graphics was being sent to a phantom screen (i.e. attached to a virtual monitor that didn't exist). Eventually I was able to set the unused screen as disabled, and make sure that all of the graphics content was sent to the correct and only active monitor. I have seen other bug reports elsewhere that users still have problems with dual monitors with plasma, where graphics content goes to the wrong screen, but that is a separate although related problem. Once I was able to set the system to have only a single active monitor there were no further problems for me. The resolution is described in https://bugs.kde.org/show_bug.cgi?id=367822#c8
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.