(In reply to Troy Dawson from comment #0)
> Both of these problems only show up on kernel 4.18.0-358.el8 and go away
> when you boot into an older kernel.

Which older version(s) have you tested, specifically?

As someone who has encountered this bug, I can tell you that 4.18.0-348.el8 (the immediately predecessor version) works fine.

Both 4.18.0-348.2.1.el8_5.x86_64 and 4.18.0-348.el8.x86_64 work correctly.

duplicate I raised here, Bug 2040536

Issue also in kernel 4.18.0-365.el8.x86_64

(Setting NEEDINFO on myself to make sure I take a look at this)

Yeah, I can reproduce this on a VM using virgl just fine. Will start looking into this

I just found something similar on the KDE bugs.
https://bugs.kde.org/show_bug.cgi?id=445449
https://bugs.kde.org/show_bug.cgi?id=445385

Their bug is dealing with long sddm shutdown time.  It started with the 5.15.2 kernel, and goes away if they go back to the 5.14.16 kernel.
I am seeing these long sddm shutdowns as well, but since they don't stop you from logging in, I didn't worry about them.

Still investigating, but I wanted to put this information here incase anyone else wants to look as well.

I did want to note one thing I noticed when diagnosing this issue on my end. Switching to another TTY and using `loginctl unlock-session' did not unlock the session. In addition, there was some indication from the logs that the session might not have been registering properly with the systemd system.

Issue also in kernel 4.18.0-373.el8.x86_64.

Still present with kernel-4.18.0-383.el8.x86_64 as well.

I've done some more debugging.
I'm not at an answer yet, but this is what I've found thus far.
It seems there are several things besides sddm that fail on the newer kernels (kscreenlocker_greet, akonadi, sddm-greeter) but I'll stick to sddm-greeter.

sddm-greeter crashes each time it starts, thus the blank/black screen.
This is the core_backtrace that I got from it.

{   "signal": 6
,   "executable": "/usr/bin/sddm-greeter"
,   "stacktrace":
      [ {   "crash_thread": true
        ,   "frames":
              [ {   "address": 140698901846607
                ,   "build_id": "d525c5b11962d363f9e9d3c119d2d46c92a0e3f5"
                ,   "build_id_offset": 322127
                ,   "function_name": "raise"
                ,   "file_name": "/lib64/libc.so.6"
                }
              , {   "address": 140698901663157
                ,   "build_id": "d525c5b11962d363f9e9d3c119d2d46c92a0e3f5"
                ,   "build_id_offset": 138677
                ,   "function_name": "abort"
                ,   "file_name": "/lib64/libc.so.6"
                }
              , {   "address": 140698915831879
                ,   "build_id": "6699bdd7da7c9ed74fd752ae36caf4a04a42ddc2"
                ,   "build_id_offset": 725063
                ,   "function_name": "qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) [clone .cold.117]"
                ,   "file_name": "/lib64/libQt5Core.so.5"
                }
              , {   "address": 140698924449279
                ,   "build_id": "db93a4bda87e9b90d8dd083b00d903b020509acc"
                ,   "build_id_offset": 1424895
                ,   "function_name": "QGuiApplicationPrivate::createPlatformIntegration()"
                ,   "file_name": "/lib64/libQt5Gui.so.5"
                }
              , {   "address": 140698924450677
                ,   "build_id": "db93a4bda87e9b90d8dd083b00d903b020509acc"
                ,   "build_id_offset": 1426293
                ,   "function_name": "QGuiApplicationPrivate::createEventDispatcher()"
                ,   "file_name": "/lib64/libQt5Gui.so.5"
                }
              , {   "address": 140698917900745
                ,   "build_id": "6699bdd7da7c9ed74fd752ae36caf4a04a42ddc2"
                ,   "build_id_offset": 2793929
                ,   "function_name": "QCoreApplicationPrivate::init()"
                ,   "file_name": "/lib64/libQt5Core.so.5"
                }
              , {   "address": 140698924458115
                ,   "build_id": "db93a4bda87e9b90d8dd083b00d903b020509acc"
                ,   "build_id_offset": 1433731
                ,   "function_name": "QGuiApplicationPrivate::init()"
                ,   "file_name": "/lib64/libQt5Gui.so.5"
                }
              , {   "address": 140698924461720
                ,   "build_id": "db93a4bda87e9b90d8dd083b00d903b020509acc"
                ,   "build_id_offset": 1437336
                ,   "function_name": "QGuiApplication::QGuiApplication(int&, char**, int)"
                ,   "file_name": "/lib64/libQt5Gui.so.5"
                }
              , {   "address": 93952641413531
                ,   "build_id": "598bb947ec337a74313071c2c3e93758253446eb"
                ,   "build_id_offset": 111003
                ,   "function_name": "main"
                ,   "file_name": "/usr/bin/sddm-greeter"
                } ]
        } ]
}

I don't see anything that really points to the kernel, so I don't know why going back to an older kernel fixes things.
But I see alot of qt5 stuff.  There is and updated qt5 released for CentOS STream 8, I'm going to see if that does anything.

FYI, just checked on CentOS Stream 9, and SDDM works correctly, whereas the latest CentosStream8 it fails (black screen as descrived above).
Both of the OSes installed today in the minimal "Custom Operating System" setup, enabled EPEL, installed openbox for a minimal session.

Could it be related to https://bugzilla.redhat.com/show_bug.cgi?id=2057419 ?
If so, already pushed to F36... Could it be backported to EPEL?

(In reply to Piotr Golonka from comment #15)
> FYI, just checked on CentOS Stream 9, and SDDM works correctly, whereas the
> latest CentosStream8 it fails (black screen as descrived above).
> Both of the OSes installed today in the minimal "Custom Operating System"
> setup, enabled EPEL, installed openbox for a minimal session.

Correct, this only affect CentOS Stream 8 / epel8.
CentOS Stream 9 / epel9 is unaffected.
But it would be good to figure out what the problem is incase it comes up in 9.

(In reply to Piotr Golonka from comment #16)
> Could it be related to https://bugzilla.redhat.com/show_bug.cgi?id=2057419 ?
> If so, already pushed to F36... Could it be backported to EPEL?

That is the most promising thing yet.  Thank you very much.
I especially like that this line is removed
https://github.com/sddm/sddm/pull/1522/files#diff-d7898f8a43d0f15c2f009d1c0ac2efd089ee8b297f38e8f12c1d93a78bfa4b5eL57

I'll give that a try and see what happens.

It should be reasonably safe to backport sddm from Fedora to EPEL, and indeed I'd recommend doing so, since that code is much closer to the latest upstream code.

*** This bug has been marked as a duplicate of bug 2082719 ***

Turns out this was a RHEL 8.6 kernel bug after all, but it was with process management.

"qt (and perhaps something else) rightly assumes that if the kernel supports P_PIDFD (qt
does the runtime check), then poll(pidfd) should work too, because
("pidfd: add P_PIDFD to waitid()") was the last one of those that became
available in kernel releases."

I am going to mark this as a duplicate of that bug.
That is a private bug, and I apologize to those that will not be able to see it's updates.  But I will keep the sddm bug open and do the major updates that can be public, on that bug.

*** This bug has been marked as a duplicate of bug 2044587 ***