Description of problem: Note: This is a split from bug 2067151 and covers one particular issue discovered there. I installed Fedora-KDE-Live-x86_64-36_Beta-1.4.iso in basic graphics mode in BIOS mode. No problems during installation. After booting into the installed system and logging in, there was ~30 seconds of black screen, before the login spinner appeared and then the desktop. After working with the desktop for a few minutes (1-2 minutes in estimate), the screen went completely black and I couldn't recover it. Ctrl+Alt+Fn combo didn't work or didn't help, just black screen. However, after pressing the power button shortly, I saw a text console with systemd messages about services being shut down (but it seemed to hang at that point). After a hard reset and a new boot, the same problem repeated. See the following logs: attachment 1867785 [details] system journal when KDE X11 session goes black screen on BIOS attachment 1867786 [details] Xorg.0.log when KDE X11 session goes black screen on BIOS attachment 1867787 [details] rpm -qa output attachment 1867788 [details] lspci output The screen going black seems to start with this line in the journal: bře 23 13:03:42 localhost-live akonadi_mailmerge_agent[1740]: The X11 connection broke (error 1). Did the X11 server die? But I don't see any further details about this issue, neither in journal nor in Xorg.log. F35 KDE works just fine on the same system. See bug 2067151 comment 25 for a summary. The hardware used is Thinkpad T480s with: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) Version-Release number of selected component (if applicable): Fedora-KDE-Live-x86_64-36_Beta-1.4.iso xorg-x11-server-Xorg-1.20.14-4.fc36.x86_64 xorg-x11-drv-vesa-2.5.0-2.fc36.x86_64 kwin-5.24.3-3.fc36.x86_64 How reproducible: always Steps to Reproduce: 1. install KDE Live in basic graphics mode in BIOS mode 2. reboot 3. notice a black screen delay during login 4. work for a few minutes, see the display go completely black and never recover (except during poweroff, partially).
Proposing as a Final blocker: "The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware. " https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#.27Basic_graphics_mode.27_boot_mode_behavior
Same behaviour in LG Gram 17: # lspci 00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01) 00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) 00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01) Finally reverted system to F35 and everything works fine again.
Sorry, blocker decision was based on +3 votes in https://pagure.io/fedora-qa/blocker-review/issue/700 .
Xorg itself is at the same version between F35 and F36 (modulo a fix for gcc unrelated to any of this), so it is unlikely the problem. The vesa driver (as used here because of nomodeset), on the other hand, had been rebased to 2.5.0 in F36 and contains a few changes: https://lists.x.org/archives/xorg-announce/2020-September/003060.html Even though nothing stands out as a probable culprit in this changelog, I wonder if building/installing xorg-x11-drv-vesa-2.5.0 (using the same src.rpm from F36) on F35 and rebooting with "nomodeset" would reprocuce the issue. If it does, then that would reduce the scope of investigations to the vesa driver.
(In reply to Olivier Fourdan from comment #4) > […] > Even though nothing stands out as a probable culprit in this changelog, I > wonder if building/installing xorg-x11-drv-vesa-2.5.0 (using the same > src.rpm from F36) on F35 and rebooting with "nomodeset" would reprocuce the > issue. If it does, then that would reduce the scope of investigations to the > vesa driver. I've spawned a scratch build of vesa 2.5.0 for Fedora 35 here if someone is wants to give that a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=84970233 Once installed, reboot with "nomodeset" and see if the problem occurs. FWIW, I am trying here as well.
Olivier, I first tested with a fully updated F35, and then also with the updated vesa from comment 5. I didn't see any issues with nomodeset in any of those cases.
Yeah neither did I, I guess that rules out a problem with the vesa driver then (unsurprisingly)…
Me neither. Still working fine. # rpm -q xorg-x11-drv-vesa xorg-x11-drv-vesa-2.5.0-2.fc35.x86_64 # cat /proc/cmdline BOOT_IMAGE=(hd0,gpt8)/boot/vmlinuz-5.16.18-200.fc35.x86_64 root=UUID=71a5f6bf-400b-4161-807e-e10f769b542c ro nomodeset
Created attachment 1870169 [details] Logs system not frozen but KDE crashed I Reinstaled -fedora 36 KDE in my laptop from scratch. Using KDE in wayland also gets frozen system. I made a lot of testing so trying to explain properly what happens. 1. Booting KDE ISO works properly, allowing me to install Fedora 36 Beta 1.4 in my LG Gram 17 laptop 2. Booting the installed O.S. goes to sddm login window. I can connect to other console Ctrl+F4, login and work properly from text console. Also I can stay in sddm without issues, moving cursor, typing user, select wayland in plasma mode combobox, etc. etc. I can sa¡tay in sddm all the time I want 3. Then login to KDE wayland. System seams to work properly, but after 10-15 seconds mouse cursor got frozen, and I dan't do nothing, even Ctrl+F4 diesb't works, only way to continue is pressing power button for more than 4 seconds and poweroff physically. 4. I found a workaround, Just after login in into KDE Wayland, I can go to text console Ctrl+F4 and stay there. Then, After 10-15 seconds I notice network WIFI goes down, but I can still use the system from text console, so now system is not frozen. Returning to graphical console, and I found I'm in sddm login screen. I can stay there as much time as I want, but if I try to login, then system is frozen inmediately. I don't know how I can help more, but I'll attach some logs from journalctl, lspci, lsmod and Xorg logs.
> After booting into the installed system and logging in, there was ~30 seconds of black screen, before the login spinner appeared and then the desktop. After working with the desktop for a few minutes (1-2 minutes in estimate), the screen went completely black and I couldn't recover it Gotta chime in here since, i have EXACTLY the same issue, but on nvidia proprietary driver (v. 510) and UEFI installation. Both X11 and Wayland sessions are affected with following symptoms: - SDDM -> Plasma transition takes around 30 seconds - After a minute screens unconditionally go blank, and after some time start blinking as if changing modes The only error in logs is as already mentioned "The X11 connection broke (error 1). Did the X11 server die?" The logs also show that after this happens, logind goes into an infinite cycle, trying to spawn new session over and over again, and each session promptly finishes, again with no visible error. Other observations (some probably unrelated, but maybe useful): - It's also impossible to drop down to TTY from SDDM screen (ctrl+alt+f3), as screen goes blank and console never comes up - Attempt to boot into multi-user.target gets stuck on "Loading nvidia modesetting driver" - nouveau driver works fine on installed system, but kde spin is unbootable (system lockup as soon as plasma splash shows up) - kdeneon with the same 510 driver but older kernel and the rest of the stack works fine Tell me if i can get any other info
Did some more testing - Everything netinstall works fine (forgot to mention it in first post, since originally that was the only way to install plasma desktop for me) - Workstation (gnome) works fine Now the interesting part: - Kde session launched from gdm works fine. Still can't access tty on nvidia proprietary drivers though - Gnome session launched from sddm exhibits described issue (crash after 1 minute) - "rolling back" to 5.16.7-200 kernel picked from f35 effectively solves all issues (tty can be accessed normally and sddm does not trigger x11 crash anymore) While there may also be incompatibilies with proprietary drivers (in my case specifically - nvidia+uefi), could this overall set of issues be related to efifb->simpledrm transition? Kwin had an issue with simpledrm (https://bugs.kde.org/show_bug.cgi?id=446804) that was patched in january. As far as i can see, SDDM wasn't?
(In reply to Mikhail Shchemelev from comment #11) > Did some more testing > > - Everything netinstall works fine (forgot to mention it in first post, > since originally that was the only way to install plasma desktop for me) > - Workstation (gnome) works fine > > Now the interesting part: > - Kde session launched from gdm works fine. Still can't access tty on nvidia > proprietary drivers though > - Gnome session launched from sddm exhibits described issue (crash after 1 > minute) > - "rolling back" to 5.16.7-200 kernel picked from f35 effectively solves all > issues (tty can be accessed normally and sddm does not trigger x11 crash > anymore) > > While there may also be incompatibilies with proprietary drivers (in my case > specifically - nvidia+uefi), could this overall set of issues be related to > efifb->simpledrm transition? > Kwin had an issue with simpledrm > (https://bugs.kde.org/show_bug.cgi?id=446804) that was patched in january. > As far as i can see, SDDM wasn't? SDDM starts a rootless X11 session for the greeter by default since I reverted the Wayland greeter default. I personally use the Wayland greeter on my machine, and this issue is not present there because kwin_wayland is used there instead of an X server. The rootless X11 session is the same thing that GDM does when it can't do Wayland, and it seems to die the same way there in that circumstance.
(In reply to Mikhail Shchemelev from comment #10) > > Other observations (some probably unrelated, but maybe useful): > - It's also impossible to drop down to TTY from SDDM screen (ctrl+alt+f3), > as screen goes blank and console never comes up I believe this might be fixed with https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 There was a refreshed version of a patch we have that was merged that seemingly looks like helps with this issue: https://github.com/sddm/sddm/pull/1532
> The rootless X11 session is the same thing that GDM does when it can't do Wayland, and it seems to die the same way there in that circumstance. Ah, i didn't think about that. Alas, can't confirm on my machine. Forced gdm into X11 mode, and it seems to be working fine. > I believe this might be fixed with https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 > There was a refreshed version of a patch we have that was merged that seemingly looks like helps with this issue: https://github.com/sddm/sddm/pull/1532 Maybe i did something wrong (i updated sddm and sddm-x11 from that build), but it does not seem to help. Both the crash and and tty inaccessibility persist. Then i replaced sddm-x11 with wayland package and it just locks up after loading (mouse cursor can be moved, but all controls are unresponsive). That is on nvidia drivers, on nouveau it just crashes immediately At this point i think that TTY not loading is probably a completely separate issue, related to nvidia drivers not supporting simpledrm (which is apparently not new [1], [2]). And sddm-x11 crashing with no survivors under simpledrm is still a thing unto itself [1] https://forums.developer.nvidia.com/t/510-39-01-on-5-16-0-kernel-green-screen/200476 [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B7V5AUF5FO7HEXMHJWQKDKZPBBRPRSIR/#EFUBUSHNT5K7MSHWRFMALKRFBSEUG62R
Can folks try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690
> Can folks try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690 It seems this one works for me (nvidia, uefi). Delay between login action and session loading is gone, the crash is gone. (modesetting/tty issue on nvidia drivers persists, but that's out of scope, i guess)
(In reply to Neal Gompa from comment #15) > Can folks try this scratch build? > https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690 Great, this fixes the problem on my laptop as well.
A likely duplicate - bug 2066304.
*** Bug 2066304 has been marked as a duplicate of this bug. ***
FEDORA-2022-cb655b9b47 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47
FEDORA-2022-cb655b9b47 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #20) > FEDORA-2022-cb655b9b47 has been submitted as an update to Fedora 36. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 Verified fixed once more.
*** Bug 2068273 has been marked as a duplicate of this bug. ***