Bugzilla – Bug 1178639
[nouveau] The plasma login screen freezes on kernel 5.9.1 and later
Last modified: 2022-02-21 09:19:45 UTC
Created attachment 843475 [details] xorg session log General description of the error: After installing kernel 5.9.1-1 as part of the upgrade, the Plasma login screen freezes, but the computer does not crash. You can log into the virtual console and use the computer normally. After booting from 5.8.15-1 kernel everything works fine. Steps for reproduction: 1. Install kernel 5.9.1-1. 2. Boot from this kernel. 3. The plasma login screen will freeze. What should be the correct reaction? After booting on the new kernel, the login screen should work normally and you should be able to log into the system. Additional information: Operating System: opensuse tumbleweed. Graphical environment: Plasma 5.20.2. Kernel: 5.9.1-1 - not working // 5.8.15-1 working. I have an nvidia card and I use open source drivers. Logs in attachments.
I can't reproduce that issue, so it might be hardware related. Please attach /var/log/Xorg.0.log and the journal during the relevant timeframe for more info.
Created attachment 843479 [details] Xorg log Xorg log from /var/log
Created attachment 843480 [details] Logs from journalctl
I'm attaching the logs and attaching the logs that issued the journalctl command. Logs come from the moment the login screen was frozen
Everything looks fine - X and sddm-greeter started properly and don't complain. As it's narrowed down to be caused by the kernel (nouveau?), I'll reassign.
Yesterday I received kernel 5.9.1-2 update and the problem still exists.
Could you try the kernel in OBS Kernel:stable repo? It's a newer 5.9.x kernel. If it still doesn't work, try 5.10-rc kernel from OBS Kernel:HEAD repo. If nothing helps, we'd need to report it to upstream.
kernel-default-5.9.8-3.1.gea93937.x86_64 = same as 5.9.1-1 and 5.9.1-2 login screen will freeze. kernel-default-5.10.rc3-1.1.ge72caa5.x86_64 = things are even worse here. After installing and restarting the computer, the system loading screen does not show (the one with a circle and the word "tumbleweed"), just a black screen. I am also unable to access the virtual console. The computer itself does not freeze because the LED from the disk flashes when the screen is black and then stops (as if the system was waiting to log into Plasma). The LEDs from the NumLock and CapsLock buttons react when I press the keys.
I checked the same versions but marked as vanilla and the problem is the same.
Today I received another update marked as opensuse tumbleweed 20201114-0 where there was an update for Mesa but the problem persists.
OK, thanks. Could you try to boot those (broken) upstream kernels with "nomodeset" boot option? This disables the native graphics, and we can see whether it's GPU driver that locks up or not.
I checked two versions: 5.9.1-1 default 5.9.1-2-default because I have such versions after recent updates and on both versions everything works with the added option "nomodeset". The login screen appears, all buttons work and I can logged into Plasma.
Anything known about this error? Anyone dealing with this problem?
I suppose it'd be best if you can report this to the upstream by yourself; the issue doesn't seem happening generically, rather specific to your hardware and/or configuration, after all.
And if you report to upstream (e.g. gitlab.freedesktop.org Issues), let me know the URL. I'll be on it, in case of the help from distro side, too. Thanks.
Could you please tell me where exactly to report this bug on the page you provided? I have no experience reporting software bugs and don't want to write in the wrong reporting section. Thank you very much. BTW. I have installed the latest + kernel 5.9.8-2 updates and there is still a problem.
https://gitlab.freedesktop.org/drm/nouveau/-/issues
I reported a bug. https://gitlab.freedesktop.org/drm/nouveau/-/issues/24
(In reply to Pawel from comment #8) > kernel-default-5.10.rc3-1.1.ge72caa5.x86_64 = things are even worse here. > After installing and restarting the computer, the system loading screen does > not show (the one with a circle and the word "tumbleweed"), just a black > screen. I am also unable to access the virtual console. The computer itself > does not freeze Can you ssh into the machine and obtain dmesg output?
(In reply to Jiri Slaby from comment #19) > Can you ssh into the machine and obtain dmesg output? Or set up kdump and provoke crash using sysrq-c?
Created attachment 843884 [details] dmesg kernel 5.10-rc5 After installing the 5.10.rc5-1.1.gc2cbe87-default kernel, the login screen appears and I can log into the TTY (virtual console). Previously on kernel 5.10 rc, the login screen did not appear and TTY was not available. Adds a log of dmesg. The login screen is still frozen.
I found an interesting thing. I installed the updates and the kernel 5.9.10-1 default was in them and the login screen is still frozen. But! If I disconnect the external monitor, the login screen works fine, it is possible to log into the system and you can use it. Summarizing: - if I start a computer with two monitors - the login screen is frozen - if I start my computer with the default monitor - everything works fine. I'm using a laptop. I have been using this system for two years, always on two monitors and the problem came with the 5.9.x kernel.
It's a good finding. Then could you try to plug the external monitor after booting without it? Does it show the same lock up? If yes, you might have a better chance to catch the problem. e.g. you can set the drm debug option (e.g. echo 0x0e > /sys/module/drm/parameters/debug) before plugging the monitor, then check the kernel messages. In anyway, please update the upstream report.
Created attachment 844028 [details] drm_debug_journalctl It looks like: - I unplugged the additional monitor, started the computer and the login screen worked properly - while in the login screen I connected a second monitor. Nothing was displayed on it, the login screen continued to work - logged in and after starting the environment, the second screen started as extended and everything worked fine I am attaching journalctl logs after enabling drm debugging. I checked it on kernel 5.9.1 because I needed a computer to work and it's tiresome installing updates you can't work on and undoing changes. It will test on a newer kernal if necessary.
I have updated a bug on gitlab nouveau.
Do you know more about a bug?
Forgotten one, sorry about that. Pawel, does the issue still exist? There is 5.16 kernel now in TW, so there is a change the bug was fixed meanwhile.
I switched hardware a year ago, I'm using opensuse on a virtual machine and it's working for the moment. I do not have the previous hardware to be able to check. Thread to close.
Thanks for the info, closing then.