FS#50364 - [linux] After update to kernel 4.7.0-1 plasma won't login

Attached to Project: Arch Linux
Opened by Mike Cloaked (mcloaked) - Thursday, 11 August 2016, 21:05 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 04 July 2018, 15:03 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

After update to kernel 4.7.0-1 this evening with the usual pacman -Syu my desktop ( Intel Ivybridge DQ77KB ) 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 is not active. At that point 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.



Additional info:
* package version(s)

kernel 4.7.0-1 produces this bug, but downgrading to 4.6.4-1-ARCH allows the plasma desktop login to proceed as normal to give a desktop that includes the taskbar.

* config and/or log files etc.


Steps to reproduce:
Upgrade kernel to 4.7.0-1 and reboot, then try to login at the sddm screen.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 04 July 2018, 15:03 GMT
Reason for closing:  Not a bug
Comment by Mike Cloaked (mcloaked) - Thursday, 11 August 2016, 21:42 GMT
I put the wrong log file in - attaching the correct file now.
Comment by Mike Cloaked (mcloaked) - Sunday, 14 August 2016, 09:29 GMT
The graphics card in this machine is:
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])
Subsystem: Intel Corporation Device 2036
Flags: bus master, fast devsel, latency 0, IRQ 31
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915

There are two xorg config files:
$ cat /etc/X11/xorg.conf.d/90-libinput.conf
# Match on all types of devices but tablet devices and joysticks
Section "InputClass"
Identifier "libinput pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection

Section "InputClass"
Identifier "libinput keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection

Section "InputClass"
Identifier "libinput touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
Option "Tapping" "on"
Option "DisableWhileTyping" "on"
Option "ScrollMethod" "edge"
EndSection

Section "InputClass"
Identifier "libinput touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection

Section "Device"
Identifier "Intel Graphics"
Driver "intel"
# Driver "modesetting"
# Option "AccelMethod" "uxa"
# Option "DRI" "False"
Option "TearFree" "true"
Option "DRI" "3"
EndSection

$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
# Option "AccelMethod" "uxa"
EndSection
Comment by Mike Cloaked (mcloaked) - Monday, 15 August 2016, 09:29 GMT
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. I am attaching the journal and Xorg logs for this boot, and test.
Comment by Mike Cloaked (mcloaked) - Monday, 15 August 2016, 09:30 GMT
If I revert to the intel driver, but remain on kernel 4.7 then the plasma login fails as before. I am attaching the journal and Xorg logs for this boot here.
Comment by Mike Cloaked (mcloaked) - Monday, 15 August 2016, 09:32 GMT
With the system downgraded to kernel 4.6.4-1 and using the intel driver the system boots normally and the plasma desktop works normally. Here are the journal and Xorg logs for this boot.
Comment by Mike Cloaked (mcloaked) - Monday, 15 August 2016, 15:31 GMT
I ran one other test - changing to DRI 2 and updating to kernel 4.7-1 and rebooting - the original symptoms remained the same - whether this helps in pointing to where the bug origin lies I don't know but it is an additional test and does not fix the problem.
Comment by Mike Cloaked (mcloaked) - Monday, 15 August 2016, 15:51 GMT Comment by patrick (potomac) - Monday, 15 August 2016, 17:55 GMT
if the culprit is really the kernel then you can try a git bisect :

https://git-scm.com/docs/git-bisect

a git bisect allows to find the commit which triggers the bug,

the process is simple but it can be slow if your PC is not fast for the compilation, you can use ccache in order to speed up the process :

https://wiki.archlinux.org/index.php/ccache
Comment by Mike Cloaked (mcloaked) - Sunday, 18 September 2016, 12:59 GMT
I have finally been able to resolve this problem. It turned out that way back in the history of my machine when I originally set it up, I had used a DVI monitor, and then a few days later plugged in an HDMI monitor and had the two monitors connected for a short period whilst I configured the displays, and HDMI monitor after that has been the only monitor on the machine for the following three years until now. However removing the original DVI monitor that was originally plugged in as a second monitor gave a phantom screen, that was presented to KDE4 and then later to plasma as a unified screen output, and the original panel that was assigned to the old DVI monitor had been displayed within plasma just fine on the primary HDMI monitor until the kernel was upgraded to the 4.7 series. At that point the phantom monitor attached to the eDP1 screen was where the panel was being displayed and therefore no longer visible on the primary HDMI display.
So in order to resolve this issue I logged on with kernel 4.6.4-1 running with the erroneously assigned panel still displayed on the primary real monitor. Then unlocking the plasma widgets, and removing the panel using the panel controls, I then created a new default panel, configured it, and locked the widgets again. Logging out and back in displayed the newly created panel correctly on the primary monitor.

Then adjusting the xorg config to include the following lines allowed logging out and back in with no phantom screen detected:

Section "Monitor"
Identifier "HDMI2"
Option "Enable" "true"
EndSection

Section "Monitor"
Identifier "eDP1"
Option "ignore" "true"
EndSection

Then upgrading the kernel to 4.7.4-1 and rebooting, allows the login from the sddm screen to proceed normally and completes without any problem including having the panel displayed on the only screen detected by kwin.
The xrandr output before and after these changes shows that prior to the steps detailed above there was a phantom eDP1 screen, but afterwards there is only a single HDMI2 screen - and now all is well.

I also found that Martin Graeslin has commented on the multi-screen issue in the past at
https://blog.martin-graesslin.com/blog/2015/10/some-thoughts-on-the-quality-of-plasma-5/ and there is another post also mentioning this issue at: https://vizzzion.org/blog/2016/05/multiscreen-in-plasma-5-7-and-beyond/

So although the problem is resolved in my case, it looks like there are still possible remnants of problems for systems where more than one monitor has been connected and during multi-screen operation some screen configs have been changed which can become an issue when the additional monitors are later removed. Therefore please close this bug as my issue is resolved.

Loading...