Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2070130 - Basic graphics mode broken for KDE BIOS mode, screen goes black in minutes
Summary: Basic graphics mode broken for KDE BIOS mode, screen goes black in minutes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://ask.fedorapro...
: 2066304 2068273 (view as bug list)
Depends On:
Blocks: F36FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-03-30 13:13 UTC by Kamil Páral
Modified: 2022-05-03 14:43 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-05 00:17:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Logs system not frozen but KDE crashed (deleted)
2022-04-02 13:54 UTC, Vicente Salvador
no flags Details

Description Kamil Páral 2022-03-30 13:13:33 UTC
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).

Comment 1 Kamil Páral 2022-03-30 13:14:25 UTC
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

Comment 2 Vicente Salvador 2022-03-30 17:53:45 UTC
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.

Comment 3 Adam Williamson 2022-03-30 22:30:06 UTC
Sorry, blocker decision was based on +3 votes in https://pagure.io/fedora-qa/blocker-review/issue/700 .

Comment 4 Olivier Fourdan 2022-03-31 09:44:37 UTC
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.

Comment 5 Olivier Fourdan 2022-03-31 10:15:45 UTC
(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.

Comment 6 Kamil Páral 2022-03-31 14:08:19 UTC
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.

Comment 7 Olivier Fourdan 2022-03-31 14:14:36 UTC
Yeah neither did I, I guess that rules out a problem with the vesa driver then (unsurprisingly)…

Comment 8 Vicente Salvador 2022-03-31 22:18:40 UTC
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

Comment 9 Vicente Salvador 2022-04-02 13:54:01 UTC
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.

Comment 10 Mikhail Shchemelev 2022-04-03 16:09:29 UTC
> 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

Comment 11 Mikhail Shchemelev 2022-04-03 19:51:13 UTC
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?

Comment 12 Neal Gompa 2022-04-03 20:31:25 UTC
(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.

Comment 13 Neal Gompa 2022-04-03 20:33:41 UTC
(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

Comment 14 Mikhail Shchemelev 2022-04-03 21:15:12 UTC
> 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

Comment 15 Neal Gompa 2022-04-03 22:18:30 UTC
Can folks try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690

Comment 16 Mikhail Shchemelev 2022-04-04 07:04:42 UTC
> 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)

Comment 17 Kamil Páral 2022-04-04 12:31:25 UTC
(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.

Comment 18 Kamil Páral 2022-04-04 15:07:02 UTC
A likely duplicate - bug 2066304.

Comment 19 Geoffrey Marr 2022-04-04 15:40:51 UTC
*** Bug 2066304 has been marked as a duplicate of this bug. ***

Comment 20 Fedora Update System 2022-04-04 18:11:14 UTC
FEDORA-2022-cb655b9b47 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47

Comment 21 Fedora Update System 2022-04-05 00:17:01 UTC
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.

Comment 22 Kamil Páral 2022-04-05 06:15:41 UTC
(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.

Comment 23 P D 2022-04-05 13:13:28 UTC
*** Bug 2068273 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.