You are not logged in.
Today 9/23/201 Did Full Upgrade, after reboot, user [myself] tries to start Gnome from tty
gnome under wayland using this command as of nov-2019
Last Full System Upgrade was 08-11-2021 no problem on this machine at that time.
env MOZ_ENABLE_WAYLAND=1
MUTTER_ALLOW_HYBRID_GPUS=1
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
gome-shell core dumps
Then ran sway to normal usage.
Then tried startx with the following .xinitrc (running normal)
xset -dpms ; xset s off ; xset noblank
exec gnome-session
Looked at archWiki on gnome also ran shell okay
gnome-shell --wayland
Search on arch bbs on help nor google for problem on arch gnome-session
Last edited by carlday (2021-10-01 23:15:55)
Offline
you shouldn't need an explicit dbus-run-session. In any case what's the coredump: https://wiki.archlinux.org/title/Core_d … _core_dump
Offline
Tried 9/24 another Full upgrade on an Intel only type system running gnome as the GUI
the cmd from tty (from archwiki-gnome)
After reboot did this cmd
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
Gnome-session failed with same error as above (here is EXACT ERROR MESSAGE:
OHno Something has gone wrong
A problem has occurred and the system can't recover
Please Logout and try again
this happened 9/24, journal shows gnome-shell core-dump
ON another computer Full upgraded 9/18, everything thing look okay on upgrade.
Today 9/24 booted the 9/18 system-upgrade <- did not have the gnome-session error
Started gnome with same 1 line from tty, gnome looked NORMAL
Then logout back to tty, journal showed gnome-shell core dumping on this normal upgrade?
Also looked at upgrade 9/13 box NO gnome-session error just gnome-shell dump
Maybe GNOME 41 will be better
Last edited by carlday (2021-09-26 06:12:00)
Offline
Post the coredump to have at least some possibility for checking what is wrong.
Offline
Here is listing of some of the Gnome-shell cores not sure if this Gnome session problem
~ls -l /var/lib/systemd/coredump/
total 90176
-rw-r----- 1 root root 18389104 Sep 23 12:54 core.gnome-shell.666.3e922f6b970f4cc584e20db142194a9e.2062.1632426870000000.zst
-rw-r----- 1 root root 18466688 Sep 23 12:15 core.gnome-shell.666.3e922f6b970f4cc584e20db142194a9e.519.1632424518000000.zst
-rw-r----- 1 root root 18573047 Sep 24 16:16 core.gnome-shell.666.64ec3bc4a06841148100d5c425c0fb9e.503.1632525402000000.zst
-rw-r----- 1 root root 18477443 Sep 24 01:41 core.gnome-shell.666.942ce8c997694f10ada0f9948c4f0152.38765.1632472859000000.zst
-rw-r----- 1 root root 18421343 Sep 23 15:06 core.gnome-shell.666.942ce8c997694f10ada0f9948c4f0152.967.1632434778000000.zst
file upload on to filebin.net 6 days
never tried a bin before. the url tag does not look okay for file?
the file url= https://filebin.net/6fpwawa5dms78ui0
Offline
You normally just need to run the set of commands I linked to to post a backtrace
Offline
coredumpctl links thru the systemd-journal to the core file ?
then thru gdb via coredumpctl gets a backtrace.?
Can gdb run standalone on the above corefiles to get the backtrace ie gdb bt file?
GDB standalone stated was a seq fault
As for the tty command to start gnome-session, had read gnome was defaulted to wayland session.
Just tring what the wiki said to do
Offline
From user tty gdb ran with a core file got bt , could NOT remember how to capture that output.
Started gnome with wayland normal, did gdb got bt saved to file.
coredumpctl could not find any dumps.
Logoff, journalctl shows dump on gnome-shell.
log gnome via X, went thru the bt capture steps
gdb) bt
#0 0x00007fc9aa5ac720 in st_focus_manager_remove_group () at /usr/lib/gnome-shell/libst-1.0.so
#1 0x00007fc9ab5e4d8f in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#2 0x00007fc9ab600718 in () at /usr/lib/libgobject-2.0.so.0
#3 0x00007fc9ab601dd9 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#4 0x00007fc9ab602330 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#5 0x00007fc9aaa96696 in () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#6 0x00007fc9aa5d337c in () at /usr/lib/gnome-shell/libst-1.0.so
#7 0x00007fc9ab5e6b8a in g_object_run_dispose () at /usr/lib/libgobject-2.0.so.0
#8 0x00007fc9aaa93ed5 in clutter_actor_destroy () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#9 0x00007fc9aaa96e84 in () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#10 0x00007fc9ab5e4cc9 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#11 0x00007fc9ab600681 in () at /usr/lib/libgobject-2.0.so.0
#12 0x00007fc9ab601dd9 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#13 0x00007fc9ab602330 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#14 0x00007fc9aaa96696 in () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#15 0x00007fc9aa5d337c in () at /usr/lib/gnome-shell/libst-1.0.so
#16 0x00007fc9ab5e6b8a in g_object_run_dispose () at /usr/lib/libgobject-2.0.so.0
#17 0x00007fc9aaa93ed5 in clutter_actor_destroy () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#18 0x00007fc9aaa96e84 in () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#19 0x00007fc9ab5e4d8f in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#20 0x00007fc9ab600681 in () at /usr/lib/libgobject-2.0.so.0
#21 0x00007fc9ab601dd9 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#22 0x00007fc9ab602330 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#23 0x00007fc9aaa96696 in () at /usr/lib/mutter-8/libmutter-clutter-8.so.0
#24 0x00007fc9aa5d337c in () at /usr/lib/gnome-shell/libst-1.0.so
#25 0x00007fc9ab5f1301 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#26 0x00007fc9aabe6959 in () at /usr/lib/libgjs.so.0
#27 0x00007fc9aabf0e6f in () at /usr/lib/libgjs.so.0
#28 0x00007fc9a80066fb in () at /usr/lib/libmozjs-78.so
#29 0x00007fc9a7fffa16 in () at /usr/lib/libmozjs-78.so
#30 0x00007fc9a8434258 in () at /usr/lib/libmozjs-78.so
#31 0x00007fc9a87b9cd0 in () at /usr/lib/libmozjs-78.so
#32 0x00007fc9a87ba06c in () at /usr/lib/libmozjs-78.so
#33 0x00007fc9a87b9b0b in () at /usr/lib/libmozjs-78.so
#34 0x00007fc9a87ba06c in () at /usr/lib/libmozjs-78.so
#35 0x00007fc9a84391e3 in () at /usr/lib/libmozjs-78.so
#36 0x00007fc9a7cbccc7 in () at /usr/lib/libmozjs-78.so
#37 0x00007fc9a7cb8c61 in () at /usr/lib/libmozjs-78.so
#38 0x00007fc9a7cb73f6 in () at /usr/lib/libmozjs-78.so
#39 0x00007fc9a8172044 in () at /usr/lib/libmozjs-78.so
#40 0x00007fc9a8171f0f in JSRuntime::destroyRuntime() () at /usr/lib/libmozjs-78.so
#41 0x00007fc9a8171d7e in () at /usr/lib/libmozjs-78.so
#42 0x00007fc9aac02b16 in () at /usr/lib/libgjs.so.0
#43 0x00007fc9ab5f1301 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#44 0x00005649e7627471 in ()
#45 0x00007fc9aa649b25 in __libc_start_main () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
#46 0x00005649e762764e in ()
(gdb)
here is link to 2185 line systemd-journal did not edit
https://filebin.net/njrrpiy5g3jqqvi1
Offline
What I know so far
My setup is Dell XPS 15, sway + wayland
I had following upgrade
[2021-09-27T19:37:13+0100] [ALPM] upgraded linux (5.14.7.arch1-1 -> 5.14.8.arch1-1)
[2021-09-27T19:37:13+0100] [ALPM] upgraded acpi_call (1.2.1-91 -> 1.2.1-92)
[2021-09-27T19:37:13+0100] [ALPM] upgraded egl-wayland (1.1.7-1 -> 1.1.8-1)
[2021-09-27T19:37:15+0100] [ALPM] upgraded linux-firmware (20210818.c46b8c3-1 -> 20210919.d526e04-1)
[2021-09-27T19:37:15+0100] [ALPM] upgraded nvidia (470.74-2 -> 470.74-3)
It broke almost everything that could be broken
firefox could not start
#0 0x00007fdf68f88773 wl_display_read_events (libwayland-client.so.0 + 0x77>
#1 0x00007fdf68f88f54 wl_display_dispatch_queue (libwayland-client.so.0 + 0>
#2 0x00007fdf68f891e0 wl_display_roundtrip_queue (libwayland-client.so.0 + >
#3 0x00007fdf645425d5 n/a (libxul.so + 0x75835d5)
#4 0x00007fdf615e288a n/a (libxul.so + 0x462388a)
kitty would just hang
a lot of other application would start slowly and produce some errors in journalctl
tried starting
gnome-shell --wayland
it works but produces this in the logs
#0 0x00007f9ef477e720 st_focus_manager_remove_group (libst-1.0.so + 0x1e720)
#1 0x00007f9ef57b6d8f g_closure_invoke (libgobject-2.0.so.0 + 0x12d8f)
#2 0x00007f9ef57d2718 n/a (libgobject-2.0.so.0 + 0x2e718)
#3 0x00007f9ef57d3dd9 g_signal_emit_valist (libgobject-2.0.so.0 + 0x2fdd9)
#4 0x00007f9ef57d4330 g_signal_emit (libgobject-2.0.so.0 + 0x30330)
#5 0x00007f9ef4c68696 n/a (libmutter-clutter-8.so.0 + 0x3b696)
removing nvidia driver completely sort of fixed the problem, but everything would still lag a lot starting kitty would take 10 seconds
after removing eglexternalplatform and egl-wayland everything is normal again
not a perfect solution since I use nvidia driver with pytorch from time to time
I do not know how everything interact under the hood in wayland world but maybe it would help somebody find root cause of the problem
Offline
What I know so far
removing nvidia driver completely sort of fixed the problem, but everything would still lag a lot starting kitty would take 10 seconds
after removing eglexternalplatform and egl-wayland everything is normal again
not a perfect solution since I use nvidia driver with pytorch from time to time
It appears to me that downgrading egl-wayland to 1.1.7 fixes the problem, no need to remove eglexternalplatform and egl-wayland.
Offline
Hi Guys, reporting in from NVIDIA. Unfortunately there's an incompatibility between the current 470 driver and version 1.1.8 of egl-wayland on pre-Turing GPUs. It affects all EGL Wayland applications, and will prevent anything from being presented to the screen. Apologies for letting this slip through, it was a testing oversight on our part. This will be fixed in the upcoming 495 driver, but until then downgrading to 1.1.7 is probably the best option.
Last edited by ekurzinger (2021-09-29 11:00:14)
Offline
This will be fixed in the upcoming 495 driver
Is this a typo? Otherwise hopefully the next version of egl-wayland can also fix it lol
(Or y'all could just get on with the times and support GBM, either works )
Last edited by Ammako (2021-09-29 01:12:55)
Offline
Nah, not a typo. The fix does need to be on the driver side. Also, the 495 driver *will* support GBM. The egl-wayland changes that broke things were in preparation for that. Instead of using EGLStreams to send frames to the compositor it now uses generic DMA-BUFs. Unfortunately, as we've discovered here, this doesn't work properly with a 470 driver due to a bug in our core EGL code.
Offline
This will be fixed in the upcoming 495 driver, but until then downgrading to 1.1.7 is probably the best option.
Yes, indeed. I noticed that I cannot launch alacritty after upgrading. I use sway with nvidia (propriearty driver) and downgrade solved the problem.
Offline
Nah, not a typo. The fix does need to be on the driver side. Also, the 495 driver *will* support GBM. The egl-wayland changes that broke things were in preparation for that. Instead of using EGLStreams to send frames to the compositor it now uses generic DMA-BUFs. Unfortunately, as we've discovered here, this doesn't work properly with a 470 driver due to a bug in our core EGL code.
470 to 495 just seems like a huge jump, it's a long time for things to remain completely broken. Or will the driver just skip straight from 470 to 495 with no other versions in-between?
GBM is pretty hype, though. Will we be able to drop egl-wayland completely?
Last edited by Ammako (2021-09-29 21:02:48)
Offline
Or will the driver just skip straight from 470 to 495 with no other versions in-between?
Yes, 495 is the next version after 470 (although we're still going to support the 470 branch for a while). Our version numbering is kinda weird, admittedly. Like how the version before 470 was 465 ¯\_(ツ)_/¯
Will we be able to drop egl-wayland completely?
No, egl-wayland is still needed. It's just that now it should work with pretty much any GBM-based compositor. It no longer requires special EGLStream support. That library is sort of the bridge between the compositor and our core EGL driver. Mesa has similar code, it's just that they don't package it as a separate library like we do.
Offline
Looks like 1.1.8 was pulled and the next pacman -Syu force-downgrades 1.1.8 back to 1.1.7, so this shouldn't really be an issue anymore.
Offline
Saw that mutter and gnome-shell had been upgraded.
Did a full UpGrade on a different small laptop intel/lenovo as of 9/30
After Restated , ran my normal wayland-gnome init-line.
The gnome-session did NOT have the gnome-session starting error screen.
sway and gnome-shell still core dump
UpGraded the 9/23 computer from Post#1 9/30, the gnome-session error did not appear on this computer either.
sway and gnome-shell still dump
Upgraded another Laptop, no Gnome-session problem, marking solved.
Last edited by carlday (2021-10-01 23:13:28)
Offline