Created attachment 1952103 [details] screencast with description Description of problem: When booting F38 KDE, sddm starts in a freeze state, not alowing the user to type a password, or chose another login for about 15 to 30 seconds (time varies from VM to VM and baremetal installs). After the freeze state ends, one can again type passoword and proceed with login. Another strange behavior related to this is the options at login screen only showing theirselves when clicking (and holding) at the virtual-keyboard button. Look at the screencast attached to see this. Version-Release number of selected component (if applicable): for versions tested see the image attached How reproducible: Always, in every F38KDE VM I tested, and in baremetal too. Steps to Reproduce: 1.start F38KDE 2.wahit for the login screen to show itself 3.try to click on the password field and type there, or choose another user Actual results: some 15 to 30 seconds delay Expected results: immediate response Additional info: first I thought it was related to this bug https://bugzilla.redhat.com/show_bug.cgi?id=2178971 but now with the fix for that one, this here is not fixed. this too might be related https://bugzilla.redhat.com/show_bug.cgi?id=2174563
Created attachment 1952104 [details] screencast and description from booting
Created attachment 1952105 [details] last version tested
Proposed as a Blocker and Freeze Exception for 38-final by Fedora user geraldosimiao using the blocker tracking app because: As described on this criterion "Default application functionality: For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test" Users expect to be able to input their passwords or choose their login as soon as the login screen shows itself with this to be chosen. Wait for more 15 to 30 seconds on a freezed screen doesnt stand for a good UX quality standard.
I have two notes: * On my machines (hardware or virtualized) the "freezing" is only for about a second, but I suppose I have quite fast hardware. * The reboot options do not just show when holding the Virtual Keyboard button, but rather with any action that unfocuses the input field: for example, focusing the ">" button by tabbing once.
Alright, well observed, click on keyboard layout or x11 and wayland session button too, unfocuses the input field and then shows the other options.
Geraldo, can you please file a separate bug for the button problem? That doesn't seem to have anything to do with the freeze problem. They seem like different bugs. Especially since this is proposed as a blocker, they should be separated, otherwise it's unclear what we're proposing to block on.
(In reply to Adam Williamson from comment #6) > Geraldo, can you please file a separate bug for the button problem? That > doesn't seem to have anything to do with the freeze problem. They seem like > different bugs. Especially since this is proposed as a blocker, they should > be separated, otherwise it's unclear what we're proposing to block on. OK, done https://bugzilla.redhat.com/show_bug.cgi?id=2180100
Probable incriminating log: sddm-greeter[7018]: Qt Quick Layouts: Polish loop detected. Aborting after two iterations. It is the last message before the "freeze"
Created attachment 1952203 [details] journalctl messages related to sddm just before and after the freeze
Created attachment 1952204 [details] Messages related to sddm just before and after the freeze
Discussed at 2023-03-20 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-03-20/f38-blocker-review.2023-03-20-16.00.html . We agreed to delay the decision on this issue as it's not yet really clear how many people the freeze would affect, and how long it will last (some testers report seeing no freeze, some seeing a much shorter freeze). We're hoping further investigation of the cause of this will allow us to make a better guess as to how many folks it's likely to affect, and how badly.
Created attachment 1952243 [details] new log from the moment it freezes I compared two F38KDE vms, same config but one with sddm-x11 and this with sddm-wayland. It seems this is different at this moment of login.
Created attachment 1952244 [details] another boot log from the moment this messages are consistent
I can reproduce the delay after boot or after log out. It's about 3 sec for me, when I have my usual 3 CPU cores assigned to the VM. When I assign just 1 CPU core, the delay is about 6 sec. So this seems to be dependent on CPU speed. The amount of RAM I give it doesn't seem to affect the delay. I also see the error message from comment 8, it seems likely to be related. Can somebody please report this to https://bugs.kde.org ?
Geraldo, please share your host system specs here, especially your CPU, thanks.
This is my host: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 Manufacturer: Acer Product Name: Aspire V3-571 System Version: V2.11 CPU: Info: quad core model: Intel Core i7-3632QM bits: 64 type: MT MCP arch: Ivy Bridge rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB Speed (MHz): avg: 1789 high: 3200 min/max: 1200/3200 cores: 1: 1446 2: 2395 3: 1863 4: 3200 5: 1200 6: 1200 7: 1795 8: 1217 bogomips: 35121 Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Created attachment 1952787 [details] VM specifications CPU
Created attachment 1952788 [details] VM config xml - CPU
Created attachment 1952789 [details] Complete XML of this VM
Upstream: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2766
(In reply to Alessandro Astone from comment #20) > Upstream: > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2766 As suggested by Alessandro, I tested this change at both my F37KDE host, and F38KDE VM, and it worked for the freeze problem, no more waiting time at login screen (edited both breeze and breeze fedora themes) :D One sideffect of this is that now keyboard layouts at the menu button on login screen gets scrambled, no more in alphabetical order.
Another PR is in: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2767
(In reply to Kamil Páral from comment #22) > Another PR is in: > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2767 I tested this new patch, following guidance from aleasto, and it did fix correctly the bug, without side-effects (keyboard layouts are order). Password field is responsive right from the start. User selection too, right from the start.
Created attachment 1952931 [details] screencast from the boot process with the patched sddm With last patch bug seems fixed at F38. (tested at F37 and it works great too)
FEDORA-2023-41861e76e1 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-41861e76e1
FEDORA-2023-0f0a596c1f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f0a596c1f
FEDORA-2023-0f0a596c1f has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0f0a596c1f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f0a596c1f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The updates with the fix for this bug (plasma-workspace-5.27.3-2) have been successfully tested on this machines: F38 VM Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.7-300.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 1.9 GiB of RAM Graphics Processor: llvmpipe Manufacturer: QEMU Product Name: Standard PC (Q35 + ICH9, 2009) System Version: pc-q35-7.0 F37 Baremetal Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 F36 VM Operating System: Fedora Linux 36 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.7-100.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 1.9 GiB of RAM Graphics Processor: llvmpipe Manufacturer: QEMU Product Name: Standard PC (Q35 + ICH9, 2009) System Version: pc-q35-6.2
FEDORA-2023-41861e76e1 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41861e76e1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks for testing, Geraldo.
FEDORA-2023-41861e76e1 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-0f0a596c1f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.