Bug 1178639 - [nouveau] The plasma login screen freezes on kernel 5.9.1 and later
[nouveau] The plasma login screen freezes on kernel 5.9.1 and later
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Tumbleweed
: P5 - None : Minor (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-10 18:32 UTC by Pawel
Modified: 2022-02-21 09:19 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
tiwai: needinfo? (rejestracje)


Attachments
xorg session log (5.40 KB, text/plain)
2020-11-10 18:32 UTC, Pawel
Details
Xorg log (50.87 KB, text/x-log)
2020-11-10 18:59 UTC, Pawel
Details
Logs from journalctl (178.43 KB, text/plain)
2020-11-10 19:00 UTC, Pawel
Details
dmesg kernel 5.10-rc5 (73.29 KB, text/plain)
2020-11-25 20:21 UTC, Pawel
Details
drm_debug_journalctl (524.47 KB, text/plain)
2020-12-01 19:55 UTC, Pawel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel 2020-11-10 18:32:19 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.
Comment 1 Fabian Vogt 2020-11-10 18:37:57 UTC
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.
Comment 2 Pawel 2020-11-10 18:59:20 UTC
Created attachment 843479 [details]
Xorg log

Xorg log from /var/log
Comment 3 Pawel 2020-11-10 19:00:15 UTC
Created attachment 843480 [details]
Logs from journalctl
Comment 4 Pawel 2020-11-10 19:00:42 UTC
I'm attaching the logs and attaching the logs that issued the journalctl command. Logs come from the moment the login screen was frozen
Comment 5 Fabian Vogt 2020-11-11 18:22:44 UTC
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.
Comment 6 Pawel 2020-11-14 09:03:24 UTC
Yesterday I received kernel 5.9.1-2 update and the problem still exists.
Comment 7 Takashi Iwai 2020-11-14 09:18:12 UTC
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.
Comment 8 Pawel 2020-11-14 22:48:39 UTC
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.
Comment 9 Pawel 2020-11-15 15:32:43 UTC
I checked the same versions but marked as vanilla and the problem is the same.
Comment 10 Pawel 2020-11-15 20:40:04 UTC
Today I received another update marked as opensuse tumbleweed 20201114-0 where there was an update for Mesa but the problem persists.
Comment 11 Takashi Iwai 2020-11-16 09:38:52 UTC
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.
Comment 12 Pawel 2020-11-16 21:08:55 UTC
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.
Comment 13 Pawel 2020-11-20 06:44:09 UTC
Anything known about this error? Anyone dealing with this problem?
Comment 14 Takashi Iwai 2020-11-23 09:59:28 UTC
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.
Comment 15 Takashi Iwai 2020-11-23 17:28:57 UTC
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.
Comment 16 Pawel 2020-11-24 06:42:59 UTC
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.
Comment 18 Pawel 2020-11-24 17:20:27 UTC
I reported a bug.

https://gitlab.freedesktop.org/drm/nouveau/-/issues/24
Comment 19 Jiri Slaby 2020-11-25 06:56:39 UTC
(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?
Comment 20 Jiri Slaby 2020-11-25 06:57:13 UTC
(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?
Comment 21 Pawel 2020-11-25 20:21:52 UTC
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.
Comment 22 Pawel 2020-11-29 17:13:04 UTC
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.
Comment 23 Takashi Iwai 2020-11-30 10:20:05 UTC
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.
Comment 24 Pawel 2020-12-01 19:55:08 UTC
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.
Comment 25 Pawel 2020-12-01 19:58:04 UTC
I have updated a bug on gitlab nouveau.
Comment 26 Pawel 2020-12-04 06:47:57 UTC
Do you know more about a bug?
Comment 27 Miroslav Beneš 2022-01-21 12:19:04 UTC
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.
Comment 28 Pawel 2022-02-18 20:56:01 UTC
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.
Comment 29 Miroslav Beneš 2022-02-21 09:19:45 UTC
Thanks for the info, closing then.