Bug 1215964 - sddm-greeter segfault on latest TW update
Summary: sddm-greeter segfault on latest TW update
Status: RESOLVED WORKSFORME
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma) (show other bugs)
Version: Current
Hardware: x86-64 openSUSE Tumbleweed
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-Mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-05 00:48 UTC by Jeff Stern
Modified: 2023-10-12 12:03 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
hwinfo - Machine 1 (1.66 MB, text/plain)
2023-10-05 00:48 UTC, Jeff Stern
Details
journalctl -b - Machine 1 (186.72 KB, text/plain)
2023-10-05 00:50 UTC, Jeff Stern
Details
hwinfo - Machine 2 (1014.29 KB, text/plain)
2023-10-07 01:43 UTC, Jeff Stern
Details
journalctl -b - Machine 2 (201.91 KB, text/plain)
2023-10-07 01:43 UTC, Jeff Stern
Details
zypp latest history - Machine 1 (77.27 KB, text/plain)
2023-10-08 06:57 UTC, Jeff Stern
Details
zypp latest history - Machine 2 (94.12 KB, text/plain)
2023-10-08 06:57 UTC, Jeff Stern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Stern 2023-10-05 00:48:52 UTC
Created attachment 869928 [details]
hwinfo - Machine 1

Upon latest update (on 4 Oct 2023)..

Linux charlie 6.5.4-1-default #1 SMP PREEMPT_DYNAMIC Wed Sep 20 05:07:04 UTC 2023 (fdd7e9e) x86_64 x86_64 x86_64 GNU/Linux

my HP Laptop now no longer boots to sddm-greeter screen. I only see the mouse and black background.

However, I can press Ctrl-Alt-F1 or Ctrl-Alt-F3 to get to a working tty, and log in.

Looking through journal, I see sddm-greeter vomitted.

I will include logs here.

It looks like there is a problem with segfaulting after not finding a Kirigami plugin? and shader problems.

Log includes the segfault.
Comment 1 Jeff Stern 2023-10-05 00:50:08 UTC
Created attachment 869929 [details]
journalctl -b - Machine 1
Comment 2 Fabian Vogt 2023-10-05 06:30:47 UTC
Does it work rcxdm restart?

If not, does it work after `sudo rm -r /var/lib/sddm/.cache` and restarting xdm again?

I don't see any changes in the last snapshot that could be relevant, unless this is somehow slowroll.
Comment 3 Jeff Stern 2023-10-07 01:14:51 UTC
Hi, Fabian, thanks for your quick response, and for your diagnostic questions.

Unfortunately..

1- rcxdm restart does not help.

2- it does not help to run `sudo rm -r /var/lib/sddm/.cache` and restart xdm again (or reboot).

:-(
Comment 4 Jeff Stern 2023-10-07 01:41:26 UTC
I now have a 2nd machine duplicating / suffering the same sddmgreeter segfault and coredump.

Below is the graphics-cards info for both machines.

==============================================================
Machine 1: HP Model 17-by0053od (laptop)
  *-display                 
       description: VGA compatible controller
       product: UHD Graphics 620
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 07
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 resolution=1600,900
       resources: irq:124 memory:b0000000-b0ffffff memory:a0000000-afffffff ioport:4000(size=64) memory:c0000-dffff

==============================================================
Machine 2: HP t730 (Thin Client) 

*-display                 
       description: VGA compatible controller
       product: Kaveri [Radeon R7 Graphics]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 1
       bus info: pci@0000:00:01.0
       logical name: /dev/fb0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=radeon latency=0 resolution=1920,1200
       resources: irq:42 memory:d0000000-dfffffff memory:e0000000-e07fffff ioport:f000(size=256) memory:feb00000-feb3ffff memory:c0000-dffff

I will attach hwinfo-m2.txt and journalctl-b-m2.txt files for this 2nd machine as well. Both are running the latest TW.

(I have a 3rd machine also running latest TW, but that one does not yet appear to have this problem.)

-JS
Comment 5 Jeff Stern 2023-10-07 01:43:05 UTC
Created attachment 869973 [details]
hwinfo - Machine 2
Comment 6 Jeff Stern 2023-10-07 01:43:40 UTC
Created attachment 869974 [details]
journalctl -b - Machine 2
Comment 7 Jeff Stern 2023-10-08 06:55:10 UTC
In today's latest TW updates (Sat Oct 7 2023), the problem now seems to be resolved on both machines.

There are between 300-400 new packages (including some removals) in today's update, so I do not know which exact packages fixed the problem.

NVTL, for the record, and in case it interests anyone, I am uploading 2 new attachments: today's segment of my /var/log/zypp/history from each machine. Whichever package(s) *did* fix the problem should be in there.
Comment 8 Jeff Stern 2023-10-08 06:57:13 UTC
Created attachment 869988 [details]
zypp latest history - Machine 1

With these updates, the problem is resolved. I do not know which package(s) fixed it.
Comment 9 Jeff Stern 2023-10-08 06:57:47 UTC
Created attachment 869989 [details]
zypp latest history - Machine 2

With these updates, the problem is resolved. I do not know which package(s) fixed it.
Comment 10 Fabian Vogt 2023-10-12 12:03:05 UTC
I guess it was Mesa, given the backtrace in the journal. Let's hope it's fixed for good and close this with WORKSFORME. Please reopen if it happens again.