This is really wired, I'll look at it, but I suggest to disable your gnome shell extensions first.

Created attachment 869469 [details]
full journal

It looks like <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6883>.

(In reply to Alynx Zhou from comment #1)
> This is really wired, I'll look at it, but I suggest to disable your gnome
> shell extensions first.

Well I see this in the log:

> [   77.699809] apollon gnome-shell[6604]: Received an X Window System error.
> [   80.237726] apollon systemd[6291]: org.gnome.Shell-disable-extensions.service: multiple trigger source candidates for exit status propagation (org.gnome.Shell@wayland.service, org.gnome.Shell@x11.service), skipping.
> [   83.621966] apollon gnome-shell[7793]: Failed to create file /run/user/17326/gnome-shell-disable-extensions: Error opening file “/run/user/17326/gnome-shell-disable-extensions”: File exists
> [  112.055741] apollon systemd[6291]: org.gnome.Shell-disable-extensions.service: multiple trigger source candidates for exit status propagation (org.gnome.Shell@wayland.service, org.gnome.Shell@x11.service), skipping.
> [  136.306974] apollon gnome-shell[9564]: Received an X Window System error.
> [  139.051904] apollon systemd[9283]: org.gnome.Shell-disable-extensions.service: multiple trigger source candidates for exit status propagation (org.gnome.Shell@wayland.service, org.gnome.Shell@x11.service), skipping.
> [  141.917881] apollon gnome-shell[10701]: Failed to create file /run/user/17326/gnome-shell-disable-extensions: Error opening file “/run/user/17326/gnome-shell-disable-extensions”: File exists

So it seems that gnome shell had already auto-disabled the extensions, no?

Do you want a core dump for analysis?

(In reply to Martin Wilck from comment #5)
> Do you want a core dump for analysis?

Currently not, I think we could try to backport the upstream fix and test it first. The error looks the same.

Fun fact: after a while in the "Oh no!" screen, the screen saver + screen lock activates and shows the correct desktop background. After entering the password, the "Oh no!" screen appears again.

Well the "upstream fix" seems to basically just ignore the error.
https://gitlab.gnome.org/jadahl/mutter/-/commit/7615c2d8dcc14b83648cf330102256060ed3b233

Another fun fact: If I hit the "Super" key, the GNOME start menu appears as usual, icons are even responsive. Only if I click a mouse button or hit a key, the "Oh no!" screen re-appears.

Captured a core with MUTTER_SYNC

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=5, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f2aee091e93 in __pthread_kill_internal (signo=5, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f2aee03f0e6 in __GI_raise (sig=sig@entry=5) at ../sysdeps/posix/raise.c:26
#3  0x0000564b6e7e82f2 in dump_gjs_stack_on_signal_handler (signo=5) at ../src/main.c:466
#4  <signal handler called>
#5  g_log_structured_array (log_level=<optimized out>, fields=0x7fffe5cc3b10, n_fields=4) at ../glib/gmessages.c:555
#6  0x00007f2aee933d2e in g_log_default_handler (log_domain=log_domain@entry=0x7f2aee58476e "libmutter", 
    log_level=log_level@entry=6, 
    message=message@entry=0x564b72ff2490 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was 'BadMatch (invalid parameter attributes)'.\n  (Details: serial 2344 error_code 8 request_code 147 (unknown)"..., 
    unused_data=unused_data@entry=0x0) at ../glib/gmessages.c:3284
#7  0x00007f2aee933fa0 in g_logv (log_domain=0x7f2aee58476e "libmutter", log_level=G_LOG_LEVEL_ERROR, 
    format=<optimized out>, args=args@entry=0x7fffe5cc3c60) at ../glib/gmessages.c:1391
#8  0x00007f2aee93424f in g_log (log_domain=log_domain@entry=0x7f2aee58476e "libmutter", 
    log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
    format=format@entry=0x7f2aee5a44d8 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was '%s'.\n  (Details: serial %ld error_code %d request_code %d (%s) minor_code %d)\n  (Note to programmers: nor"...)
    at ../glib/gmessages.c:1460
#9  0x00007f2aee4fdb7e in display_error_event (error=0x7fffe5cc3de0, x11_display=0x564b70b8ce70)
    at ../src/x11/meta-x11-errors.c:113
#10 meta_x_error (xdisplay=<optimized out>, error=0x7fffe5cc3de0) at ../src/x11/meta-x11-errors.c:136
#11 meta_x_error (xdisplay=<optimized out>, error=0x7fffe5cc3de0) at ../src/x11/meta-x11-errors.c:132
#12 0x00007f2aeddd030b in _XError (dpy=dpy@entry=0x564b706a9930, rep=rep@entry=0x564b72c73a00)
    at /usr/src/debug/libX11-1.8.6/src/XlibInt.c:1503
#13 0x00007f2aeddd0407 in handle_error (dpy=0x564b706a9930, err=0x564b72c73a00, in_XReply=<optimized out>)
    at /usr/src/debug/libX11-1.8.6/src/xcb_io.c:211
#14 0x00007f2aeddd04bd in handle_response (dpy=dpy@entry=0x564b706a9930, response=0x564b72c73a00, 
    in_XReply=in_XReply@entry=1) at /usr/src/debug/libX11-1.8.6/src/xcb_io.c:403
#15 0x00007f2aeddd216d in _XReply (dpy=dpy@entry=0x564b706a9930, rep=rep@entry=0x7fffe5cc3fa0, extra=extra@entry=0, 
    discard=discard@entry=1) at /usr/src/debug/libX11-1.8.6/src/xcb_io.c:722
#16 0x00007f2aeddd24eb in XSync (dpy=0x564b706a9930, discard=discard@entry=0) at /usr/src/debug/libX11-1.8.6/src/Sync.c:44
#17 0x00007f2aeddd258b in _XSyncFunction (dpy=<optimized out>) at /usr/src/debug/libX11-1.8.6/src/Synchro.c:35
#18 0x00007f2aec88b972 in DPMSForceLevel (dpy=0x564b706a9930, level=0) at /usr/src/debug/libXext-1.3.5/src/DPMS.c:259
#19 0x00007f2aee4eb4ed in meta_monitor_manager_xrandr_set_power_save_mode (mode=<optimized out>, manager=0x564b7073ebc0)
    at ../src/backends/x11/meta-monitor-manager-xrandr.c:183
#20 meta_monitor_manager_xrandr_set_power_save_mode (manager=0x564b7073ebc0, mode=<optimized out>)
    at ../src/backends/x11/meta-monitor-manager-xrandr.c:160
#21 0x00007f2aee48246c in power_save_mode_changed (manager=0x564b7073ebc0, pspec=<optimized out>, user_data=<optimized out>)
    at ../src/backends/meta-monitor-manager.c:454
#22 0x00007f2aeeeea448 in g_closure_invoke (closure=0x564b70740da0, return_value=0x0, n_param_values=2, param_values=0x7fffe5cc41f0, 
    invocation_hint=0x7fffe5cc4170) at ../gobject/gclosure.c:832
#23 0x00007f2aeeefd4fe in signal_emit_unlocked_R (node=node@entry=0x564b70691220, detail=detail@entry=324, 
    instance=instance@entry=0x564b70740010, emission_return=emission_return@entry=0x0, 
    instance_and_params=instance_and_params@entry=0x7fffe5cc41f0) at ../gobject/gsignal.c:3812
#24 0x00007f2aeef0482e in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, 
    var_args=var_args@entry=0x7fffe5cc4390) at ../gobject/gsignal.c:3565
#25 0x00007f2aeef049df in g_signal_emit (instance=instance@entry=0x564b70740010, signal_id=<optimized out>, detail=<optimized out>)
    at ../gobject/gsignal.c:3622
#26 0x00007f2aeeeee6c4 in g_object_dispatch_properties_changed (object=0x564b70740010, n_pspecs=<optimized out>, pspecs=<optimized out>)
    at ../gobject/gobject.c:1428
#27 0x00007f2aeeeef018 in g_object_notify_queue_thaw (object=object@entry=0x564b70740010, nqueue=nqueue@entry=0x564b72cb94b0)
    at ../gobject/gobject.c:359
#28 0x00007f2aeeef2ab0 in g_object_setv (values=<optimized out>, names=<optimized out>, n_properties=<optimized out>, 
    object=0x564b70740010) at ../gobject/gobject.c:2727
#29 g_object_setv (object=0x564b70740010, n_properties=<optimized out>, names=<optimized out>, values=<optimized out>)
    at ../gobject/gobject.c:2694
#30 0x00007f2aeeef3c0b in g_object_set_property (object=object@entry=0x564b70740010, property_name=<optimized out>, 
    value=value@entry=0x7fffe5cc45d0) at ../gobject/gobject.c:3023
#31 0x00007f2aee45fa2d in _meta_dbus_display_config_skeleton_handle_set_property (connection=<optimized out>, sender=<optimized out>, 
    object_path=object_path@entry=0x7f2ad80205c0 "/org/gnome/Mutter/DisplayConfig", 
    interface_name=interface_name@entry=0x7f2aee584138 "org.gnome.Mutter.DisplayConfig", 
    property_name=property_name@entry=0x7f2ad803f6af "PowerSaveMode", variant=variant@entry=0x7f2ad8029650, error=0x7fffe5cc4648, 
    user_data=0x564b70740010) at src/meta-dbus-display-config.c:3063
#32 0x00007f2aeeb26db8 in invoke_set_property_in_idle_cb (_data=_data@entry=0x7f2ad8005a90) at ../gio/gdbusconnection.c:4344
#33 0x00007f2aee92751e in g_idle_dispatch (source=0x7f2ad8010070, callback=0x7f2aeeb26d10 <invoke_set_property_in_idle_cb>, 
    user_data=0x7f2ad8005a90) at ../glib/gmain.c:6163
#34 0x00007f2aee92b9d8 in g_main_dispatch (context=0x564b70694890) at ../glib/gmain.c:3460
#35 g_main_context_dispatch (context=context@entry=0x564b70694890) at ../glib/gmain.c:4200
#36 0x00007f2aee92bde8 in g_main_context_iterate (context=0x564b70694890, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimized out>) at ../glib/gmain.c:4276
#37 0x00007f2aee92c09f in g_main_loop_run (loop=0x564b7229d4f0) at ../glib/gmain.c:4479
#38 0x00007f2aee4c0eb5 in meta_context_run_main_loop (context=context@entry=0x564b706927f0, error=error@entry=0x7fffe5cc4810)
    at ../src/core/meta-context.c:482
#39 0x0000564b6e7e799f in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:683


So there's indeed a similar stack involving DPMSForceLevel:

#15 0x00007f2aeddd216d in _XReply (dpy=dpy@entry=0x564b706a9930, rep=rep@entry=0x7fffe5cc3fa0, extra=extra@entry=0, 
    discard=discard@entry=1) at /usr/src/debug/libX11-1.8.6/src/xcb_io.c:722
        event = <optimized out>
        req = 0x564b72cb94b0
        response = 0x564b72fdd720
        xcb_xlib_threads_sequence_lost = <optimized out>
        error = 0x0
        c = 0x564b70711140
        reply = <optimized out>
        current = 0x564b72cb94b0
        dpy_request = <optimized out>
        __PRETTY_FUNCTION__ = "_XReply"

#16 0x00007f2aeddd24eb in XSync (dpy=0x564b706a9930, discard=discard@entry=0) at /usr/src/debug/libX11-1.8.6/src/Sync.c:44
        rep = {type = 0 '\000', revertTo = 0 '\000', sequenceNumber = 0, length = 0, focus = 1929254704, pad1 = 22091, pad2 = 0, 
          pad3 = 32554, pad4 = 3962721152, pad5 = 115}
        req = <optimized out>

#17 0x00007f2aeddd258b in _XSyncFunction (dpy=<optimized out>) at /usr/src/debug/libX11-1.8.6/src/Synchro.c:35

#18 0x00007f2aec88b972 in DPMSForceLevel (dpy=0x564b706a9930, level=0) at /usr/src/debug/libXext-1.3.5/src/DPMS.c:259
        info = 0x564b70935e30
        req = <optimized out>

#19 0x00007f2aee4eb4ed in meta_monitor_manager_xrandr_set_power_save_mode (mode=<optimized out>, manager=0x564b7073ebc0)
    at ../src/backends/x11/meta-monitor-manager-xrandr.c:183
        manager_xrandr = <optimized out>
        state = <optimized out>
        manager_xrandr = <optimized out>
        state = <optimized out>

#20 meta_monitor_manager_xrandr_set_power_save_mode (manager=0x564b7073ebc0, mode=<optimized out>)
    at ../src/backends/x11/meta-monitor-manager-xrandr.c:160
        manager_xrandr = 0x564b7073ebc0
        state = <optimized out>
#21 0x00007f2aee48246c in power_save_mode_changed (manager=0x564b7073ebc0, pspec=<optimized out>, user_data=<optimized out>)
    at ../src/backends/meta-monitor-manager.c:454
        priv = 0x564b7073eb90
        klass = <optimized out>
        mode = <optimized out>

#22 0x00007f2aeeeea448 in g_closure_invoke (closure=0x564b70740da0, return_value=0x0, n_param_values=2, param_values=0x7fffe5cc41f0, 
    invocation_hint=0x7fffe5cc4170) at ../gobject/gclosure.c:832
        marshal = 0x7f2aeeeed500 <g_cclosure_marshal_VOID__PARAM>
        marshal_data = 0x0
        in_marshal = 0
        real_closure = 0x564b70740d80
        __func__ = "g_closure_invoke"

(In reply to Martin Wilck from comment #8)
> Well the "upstream fix" seems to basically just ignore the error.
> https://gitlab.gnome.org/jadahl/mutter/-/commit/
> 7615c2d8dcc14b83648cf330102256060ed3b233

It looks like something that not so critical, and we could do nothing if that fails but only ignore it.

Now I think I need a core file to see where it failed, but looks like you need to run GNOME with env `MUTTER_SYNC=1` and then grab the core file.

I think we could not add a patch for mutter 44.4 in openSUSE:Factory, because we have mutter 45.rc in GNOME:Factory, so we could only add this fix to mutter 45 and wait for openSUSE:Factory to have mutter 45.

@Yifan What's your opinion?

238	Status
239	DPMSForceLevel(Display *dpy, CARD16 level)
240	{
241	    XExtDisplayInfo *info = find_display (dpy);
242	    register xDPMSForceLevelReq *req;
243	
244	    DPMSCheckExtension (dpy, info, 0);
245	
(gdb) 
246	    if ((level != DPMSModeOn) &&
247		(level != DPMSModeStandby) &&
248		(level != DPMSModeSuspend) &&
249		(level != DPMSModeOff))
250		return BadValue;
251	
252	    LockDisplay(dpy);
253	    GetReq(DPMSForceLevel, req);
254	    req->reqType = info->codes->major_opcode;
255	    req->dpmsReqType = X_DPMSForceLevel;
(gdb) 
256	    req->level = level;
257	
258	    UnlockDisplay(dpy);
259	    SyncHandle();
260	    return 1;
261	}

(gdb) p level
$10 = 0
(gdb) p *info->codes
$9 = {
  extension = 9,
  major_opcode = 147,
  first_event = 0,
  first_error = 0
}

The error returned from the X server (in handle_response) is

(gdb) p *err
$7 = {
  type = 0 '\000',
  errorCode = 8 '\b',
  sequenceNumber = 2344,
  resourceID = 1962,
  minorCode = 6,
  majorCode = 147 '\223',

147/6 just means the DPMS extension / DPMSForceLevel.

According to the Xorg docs, a "BadMatch" error from DPMSForceLevel means that "DPMS is disabled" (https://www.x.org/releases/X11R7.7/doc/libXext/dpmslib.html#DPMSForceLevel).
That's strange, as I surely have DPMS enabled.

(In reply to Alynx Zhou from comment #12)
> I think we could not add a patch for mutter 44.4 in openSUSE:Factory,
> because we have mutter 45.rc in GNOME:Factory, so we could only add this fix
> to mutter 45 and wait for openSUSE:Factory to have mutter 45.

Well for me this means a crash and "Oh no!" on every login attempt. I wouldn't call this "not so critical". Also, I think the upstream "fix" doesn't really fix anything; the actual problem seems to be in mutter's DPMS handling.

Just guessing, could it be that mutter calls DPMSForceLevel() before enabling DPMS?

Also, mind you that I've started seeing this after updating mutter from 44.3-4.1 to 44.4-1.1, which was just added to TW last week.

-------------------------------------------------------------------
Mon Sep  4 14:28:19 UTC 2023 - Bjørn Lie <bjorn.lie@gmail.com>

- Update to version 44.4:
  + Fix xwayland-allow-byte-swapped-clients setting.
  + Fix restoring focus when leaving the overview.
  + Fix touch move operations on subsurfaces.
  + Fix flickering when DRI driver isn't available.
  + Fix unexpected cursor changes over non-resizable windows.
  + Fix restoring maximized state of SSD windows.
  + Fix window focus unexpectedly moving to secondary monitor when
    changing workspaces.
  + Fixed crash.
  + Misc. bug fixes and cleanups.
  + Updated translations.

(In reply to Martin Wilck from comment #15)
> Also, mind you that I've started seeing this after updating mutter from
> 44.3-4.1 to 44.4-1.1, which was just added to TW last week.

Whereas the upstream issue says "I've had this issue since 44.3" (on arch linux).

(In reply to Martin Wilck from comment #13)
> That's strange, as I surely have DPMS enabled.

Hm...

$ xset q
...
DPMS (Display Power Management Signaling):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

grepping for "DPMS" in the system logs, for the case documented in comment 10:

> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): EDID for output eDP-1
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): DPMS capabilities: StandBy Suspend Off
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): EDID for output DP-1-1
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): DPMS capabilities: Off
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): EDID for output DP-1-2
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): EDID for output DP-1-3
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) modeset(0): DPMS capabilities: Off; RGB/Color Display
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (**) modeset(0): DPMS enabled
> Sep 13 11:13:51 apollon /usr/libexec/gdm/gdm-x-session[31564]: (II) Initializing extension DPMS

Sep 13 08:51:33 apollon /usr/libexec/gdm/gdm-x-session[15546]: (II) modeset(0): DPMS capabilities: StandBy Suspend Off
Sep 13 08:51:33 apollon /usr/libexec/gdm/gdm-x-session[15546]: (II) modeset(0): DPMS capabilities: Off
Sep 13 08:51:33 apollon /usr/libexec/gdm/gdm-x-session[15546]: (II) modeset(0): DPMS capabilities: Off; RGB/Color Display
Sep 13 08:51:33 apollon /usr/libexec/gdm/gdm-x-session[15546]: (==) modeset(0): DPMS enabled
Sep 13 08:51:33 apollon /usr/libexec/gdm/gdm-x-session[15546]: (II) Initializing extension DPMS
                                                 #15 0x00007f2aec88b972 
DPMSForceLevel (libXext.so.6 + 0x7972)

The modesetting driver says that DPMS is enabled, but `xset` says the opposite.
Perhaps some entity has _disabled_ DPMS after it was originally enabled?

(In reply to Alynx Zhou from comment #12)
> I think we could not add a patch for mutter 44.4 in openSUSE:Factory,
> because we have mutter 45.rc in GNOME:Factory, so we could only add this fix
> to mutter 45 and wait for openSUSE:Factory to have mutter 45.
> 
> @Yifan What's your opinion?

I agree, the GNOME 45 is on the way, and GNOME 44 will soon not be there, e.g.:

https://build.opensuse.org/request/show/1110516

So as for my perspective, porting the fix to GNOME 45 could be the most intuitive way.

Alynx provided a test package to me which solved the issue by checking first whether the display was DPMS capable and had it enabled before sending a DPMSForceLevel(). 

That test package worked nicely, thanks a lot Alynx!

The same package seems to fix bug 1210143 as well (preliminary result, needs more testing).

I decide to first submit a patch with error traps to Factory, and if my MR got merged, we could update the patch to add DPMS checks, so Factory patch will keep the same with upstream and it is easier for Factory maintainer to maintain it.

Patch accepted, upstream issue resolved, let's close this bug?

I'd prefer not to close the bug before a package with the bugfix has reached factory.

It's now in Factory.

Thanks!