Hi, After some idle time, the screen is locking itself (normal screen-lock). After unlocking it with my password, the desktop was frozen. (I can log into the desktop, the last visible Software is there but the desktop is frozen). No keyboard or mouse was working. (I could move the mouse pointer, but with no effect.) There was some keyboard error message (i've forgotten which..)-: ) in the right upper corner. Even replugging the keyboard or the mouse has no effect. After a reboot, during booting, the last picture of the frozen desktop was visible. Than i've got a normal manjaro desktop. Until the screen lock locks again (-; This bug is reproducable. (just wait for e.g. 10 minutes) Manually locking the screen instead: here the unlocking process is ok. More testing results with error messages you can find here: https://forum.manjaro.org/t/xfce-desktop-freezes-after-automated-screen-lock-manjaro-18-0-4-illyria/84717 LF
(In reply to Linuxfreak from comment #0) > No keyboard or mouse was working. (I could move the mouse pointer, but with > no effect.) Could be that the screen lock left the pointer and keyboard grabbed, which would prevent any user interaction. > [...] > More testing results with error messages you can find here: > > https://forum.manjaro.org/t/xfce-desktop-freezes-after-automated-screen-lock- > manjaro-18-0-4-illyria/84717 That seems suspicious to me: `systemd-coredump[2004]: Process 1924 (light-locker) of user 1000 dumped core.` But `light-locker` is not an xfce component.
A new behavior: I've disabled the password (light-locker). So after some time the screensaver of the monitor got active and went black. When it comes again (pressing a key or mouse movement..), the screen activates itself and the frozen desktop is also here.
Can you diable compositing to see if that helps?
Yes, if you tell me whats compositing is? light locker seems to be used by XFCE: https://github.com/the-cavalry/light-locker/issues/139 Its not a Manjaro thing.
Known users of light-locker are: elementary OS XFCE
(In reply to Linuxfreak from comment #4) > Yes, if you tell me whats compositing is? xfwm4-tweaks-settings → Compositor → Un-check "Enable display compositing" (but I really doubt it's a compositing issue, if it were, you'd see nothing on screen - It really looks like a grab issue, i.e. something keeps a grab on the keyboard/mouse and prevents from any other user interaction, and the client that last had a grab in that case would be lightdm...) > light locker seems to be used by XFCE: > > https://github.com/the-cavalry/light-locker/issues/139 > > Its not a Manjaro thing. Sure, lightdm/light-locker are not Manjaro.
Created attachment 8457 Komposit un checked Komposit un checked
You mean you don't have compositing enabled? As I said, I don't think this is a bug with xfce.
ok, now Enable display compositing un-checked, after a while the screensaver kicked in black. Deactivating the screensaver lead to a non freezing functional XFCE Desktop. So your hint helped!
(-:
(In reply to Linuxfreak from comment #9) > ok, now Enable display compositing un-checked, after a while the screensaver > kicked in black. Deactivating the screensaver lead to a non freezing > functional XFCE Desktop. So your hint helped! OK, so we're making progress. Can you please now post the output of the following commands: $ xfwm4 --version and $ xfconf-query -vl -c xfwm4
xfwm4 --version This is xfwm4 version 4.13.1git.UNKNOWN (revision UNKNOWN) for Xfce 4.13 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.5, using GTK+-3.24.8. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No xfconf-query -vl -c xfwm4 /general/activate_action bring /general/borderless_maximize true /general/box_move false /general/box_resize false /general/button_layout O|SHMC /general/button_offset 0 /general/button_spacing 0 /general/click_to_focus true /general/cycle_apps_only false /general/cycle_draw_frame true /general/cycle_hidden true /general/cycle_minimum true /general/cycle_preview true /general/cycle_raise false /general/cycle_tabwin_mode 0 /general/cycle_workspaces false /general/double_click_action maximize /general/double_click_distance 5 /general/double_click_time 250 /general/easy_click Alt /general/focus_delay 250 /general/focus_hint true /general/focus_new true /general/frame_opacity 100 /general/full_width_title true /general/horiz_scroll_opacity false /general/inactive_opacity 100 /general/maximized_offset 0 /general/mousewheel_rollup true /general/move_opacity 100 /general/placement_mode center /general/placement_ratio 60 /general/popup_opacity 100 /general/prevent_focus_stealing false /general/raise_delay 250 /general/raise_on_click true /general/raise_on_focus false /general/raise_with_any_button true /general/repeat_urgent_blink false /general/resize_opacity 100 /general/restore_on_move true /general/scroll_workspaces true /general/shadow_delta_height 0 /general/shadow_delta_width 0 /general/shadow_delta_x 0 /general/shadow_delta_y -3 /general/shadow_opacity 50 /general/show_app_icon false /general/show_dock_shadow true /general/show_frame_shadow true /general/show_popup_shadow false /general/snap_resist false /general/snap_to_border true /general/snap_to_windows false /general/snap_width 10 /general/sync_to_vblank true /general/theme Adapta-Maia /general/tile_on_move true /general/title_alignment center /general/title_font Noto Sans 10 /general/title_horizontal_offset 0 /general/titleless_maximize false /general/title_shadow_active false /general/title_shadow_inactive false /general/title_vertical_offset_active 0 /general/title_vertical_offset_inactive 0 /general/toggle_workspaces false /general/unredirect_overlays true /general/urgent_blink false /general/use_compositing false /general/vblank_mode auto /general/workspace_count 2 /general/workspace_names <<UNSUPPORTED>> /general/wrap_cycle true /general/wrap_layout true /general/wrap_resistance 10 /general/wrap_windows true /general/wrap_workspaces false /general/zoom_desktop true
Ahh today i've did an new testing update. Hmm inxi -Fxzc0 Host: Kernel: 5.0.9-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.13.3git-UNKNOWN Distro: Manjaro Linux says Xfce 4.13.3git-UNKNOWN while today xfwm4 --version This is xfwm4 version 4.13.1git.UNKNOWN ??? So either inxi or xfwm4 --version is not correct?
Try this: 1. Re-enable compositing: $ xfconf-query -c xfwm4 -p /general/use_compositing -s true 2. Set "glx" for vblank method: $ xfconf-query -c xfwm4 -p /general/vblank_mode -s glx 3. Restart xfwm4 to pick the new vblank mode: $ xfwm4 --replace & And see if that helps with the issue.
ok, PS: If i de-activate compositing, the system icons went made.. insteade.. https://forum.manjaro.org/t/icon-size-problem-in-system-tray/84971/6
So, xfconf-query -c xfwm4 -p /general/use_compositing -s true xfconf-query -c xfwm4 -p /general/vblank_mode -s glx xfwm4 --replace & [1] 1640 Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done Now i have to wait for the screensaver kicking in..
Hi Oliver, so this time, after the screensaver went active.. I had an operational xfce-desktop (-: I'll try it also with the password lock..
So good news and bad news. good news: I've waited: screensaver went black-> screen-locker went active, and showed the password and username field. After 10 min again, the screen went black. I could unlock ist and i have a functional working desktop! No freezing! So the Bug seems solved. But there are still stack trace'es right after unlocking or due to the unlocking process?? Apr 26 12:24:28 lightdm[1041]: gkr-pam: unable to locate daemon control file Apr 26 12:24:31 systemd-coredump[1053]: Process 682 (xfwm4) of ... 1000 dumped core. Stack trace of thread 682: #0 0x00007f74f7e14186 n/a (libglib-2.0.so.0) #1 0x00007f74f7e11f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007f74f7e08a49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007f74f7e10f0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007f74f816d54e n/a (libgdk-3.so.0) #5 0x00007f74f817a6e5 n/a (libgdk-3.so.0) #6 0x00007f74f7a9552a _XError (libX11.so.6) #7 0x00007f74f7a923f8 n/a (libX11.so.6) #8 0x00007f74f7a924a5 n/a (libX11.so.6) #9 0x00007f74f7a93410 _XReply (libX11.so.6) #10 0x00007f74f8936742 XIQueryDevice (libXi.so.6) #11 0x00007f74f816a1bd n/a (libgdk-3.so.0) #12 0x00007f74f817536d n/a (libgdk-3.so.0) #13 0x00007f74f8174e36 n/a (libgdk-3.so.0) #14 0x00007f74f813dea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007f74f8174aa4 n/a (libgdk-3.so.0) #16 0x00007f74f7e1a7bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007f74f7e1c739 n/a (libglib-2.0.so.0) #18 0x00007f74f7e1d6d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007f74f8445e6f gtk_main (libgtk-3.so.0) #20 0x000055dc1b8e3765 n/a (xfwm4) #21 0x00007f74f7544ce3 __libc_start_main (libc.so.6) #22 0x000055dc1b8e395e n/a (xfwm4) Stack trace of thread 693: #0 0x00007f74f76110d1 __poll (libc.so.6) #1 0x00007f74f7e1c690 n/a (libglib-2.0.so.0) #2 0x00007f74f7e1c77e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f74f7e1c7d2 n/a (libglib-2.0.so.0) #4 0x00007f74f7df7c21 n/a (libglib-2.0.so.0) #5 0x00007f74f76eda92 start_thread (libpthread.so.0) #6 0x00007f74f761bcd3 __clone (libc.so.6) Stack trace of thread 695: #0 0x00007f74f76110d1 __poll (libc.so.6) #1 0x00007f74f7e1c690 n/a (libglib-2.0.so.0) #2 0x00007f74f7e1d6d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f74f6f28568 n/a (libgio-2.0.so.0) #4 0x00007f74f7df7c21 n/a (libglib-2.0.so.0) #5 0x00007f74f76eda92 start_thread (libpthread.so.0) #6 0x00007f74f761bcd3 __clone (libc.so.6) Stack trace of thread 847: #0 0x00007f74f76f3bac pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007f74ef1011e4 n/a (nouveau_dri.so) #2 0x00007f74ef100f08 n/a (nouveau_dri.so) #3 0x00007f74f76eda92 start_thread (libpthread.so.0) #4 0x00007f74f761bcd3 __clone (libc.so.6) Apr 26 12:46:57 lightdm[1541]: gkr-pam: unable to locate daemon control file Apr 26 12:46:59 systemd-coredump[1584]: Process 1054 (xfwm4) of ... 1000 dumped core. Stack trace of thread 1054: #0 0x00007f3324e23186 n/a (libglib-2.0.so.0) #1 0x00007f3324e20f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007f3324e17a49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007f3324e1ff0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007f332517c54e n/a (libgdk-3.so.0) #5 0x00007f33251896e5 n/a (libgdk-3.so.0) #6 0x00007f3324aa452a _XError (libX11.so.6) #7 0x00007f3324aa13f8 n/a (libX11.so.6) #8 0x00007f3324aa14a5 n/a (libX11.so.6) #9 0x00007f3324aa2410 _XReply (libX11.so.6) #10 0x00007f3325945742 XIQueryDevice (libXi.so.6) #11 0x00007f33251791bd n/a (libgdk-3.so.0) #12 0x00007f332518436d n/a (libgdk-3.so.0) #13 0x00007f3325183e36 n/a (libgdk-3.so.0) #14 0x00007f332514cea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007f3325183aa4 n/a (libgdk-3.so.0) #16 0x00007f3324e297bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007f3324e2b739 n/a (libglib-2.0.so.0) #18 0x00007f3324e2c6d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007f3325454e6f gtk_main (libgtk-3.so.0) #20 0x0000563567c3f765 n/a (xfwm4) #21 0x00007f3324553ce3 __libc_start_main (libc.so.6) #22 0x0000563567c3f95e n/a (xfwm4) Stack trace of thread 1055: #0 0x00007f33246200d1 __poll (libc.so.6) #1 0x00007f3324e2b690 n/a (libglib-2.0.so.0) #2 0x00007f3324e2b77e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f3324e2b7d2 n/a (libglib-2.0.so.0) #4 0x00007f3324e06c21 n/a (libglib-2.0.so.0) #5 0x00007f33246fca92 start_thread (libpthread.so.0) #6 0x00007f332462acd3 __clone (libc.so.6) Stack trace of thread 1056: #0 0x00007f33246200d1 __poll (libc.so.6) #1 0x00007f3324e2b690 n/a (libglib-2.0.so.0) #2 0x00007f3324e2c6d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f3323f37568 n/a (libgio-2.0.so.0) #4 0x00007f3324e06c21 n/a (libglib-2.0.so.0) #5 0x00007f33246fca92 start_thread (libpthread.so.0) #6 0x00007f332462acd3 __clone (libc.so.6) Stack trace of thread 1064: #0 0x00007f3324702bac pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007f331b9721e4 n/a (nouveau_dri.so) #2 0x00007f331b971f08 n/a (nouveau_dri.so) #3 0x00007f33246fca92 start_thread (libpthread.so.0) #4 0x00007f332462acd3 __clone (libc.so.6)
After unlocking again: journalctl Apr 26 13:30:13 lightdm[1936]: gkr-pam: unable to locate daemon control file
So the issue is caused by Present not triggering the flip after the screensaver has been turned on, which is not a bug in xfwm4 but rather in the kernel. The backtrace you mention in comment 18 is unrelated to this issue though.
Out of curiosity, can you post the Xorg logs as attachment?
Olivier Fourdan referenced this bugreport in commit e07574d6e7a2dbaa08c3ba4765c6306073d9493e compositor: Revert to GLX as default vblank method (again) https://git.xfce.org/xfce/xfwm4/commit?id=e07574d6e7a2dbaa08c3ba4765c6306073d9493e
Created attachment 8461 xorg.log xorg.log
Created attachment 8462 xorg.1.log xorg.1.log
(In reply to Olivier Fourdan from comment #20) > So the issue is caused by Present not triggering the flip after the > screensaver has been turned on, which is not a bug in xfwm4 but rather in > the kernel. > > The backtrace you mention in comment 18 is unrelated to this issue though. I do not understand your comment well enough. this tip of you: xfconf-query -c xfwm4 -p /general/use_compositing -s true xfconf-query -c xfwm4 -p /general/vblank_mode -s glx xfwm4 --replace & solved the freezing desktop problem. So how is this a kernel bug? The backtrace came right after i got to the (now functional) desktop again. So ist must be related to a de-activating screensaver process?
(In reply to Linuxfreak from comment #25) > > I do not understand your comment well enough. > this tip of you: > xfconf-query -c xfwm4 -p /general/use_compositing -s true > xfconf-query -c xfwm4 -p /general/vblank_mode -s glx > xfwm4 --replace & > > solved the freezing desktop problem. > So how is this a kernel bug? Because the commands above change the vsync method from XPresent to GLX and that solves the issue. The apparent freeze comes from XPresent waiting for the VBlank notification through a call to `dri3_wait_for_msc()` that never comes up, so this is down to the kernel. There've been similar issues in the past, see https://bugs.freedesktop.org/show_bug.cgi?id=93800 > The backtrace came right after i got to the (now functional) desktop again. > So ist must be related to a de-activating screensaver process? Possibly related, yes, but that's still a different issue from the “freezing desktop” which is drm/kernel.
Hi Oliver, ok, thank you very much for your time and work! So Bug #15325 is solved? So the manajro team has to apply also your hint in comment 16 ? And the 2nd freeze was something else from the kernel? (e.g. i have to bother / ask someone else? (-;) best regrads LF
(In reply to Linuxfreak from comment #27) > So Bug #15325 is solved? Yes, as far as xfwm4 is concerned, it is. > So the manajro team has to apply also your hint in comment 16 ? No, there will be a new version of xfwm4 which uses GLX by default - By the way, this particular issue is related to the driver and does not affect all other drivers in general. > And the 2nd freeze was something else from the kernel? (e.g. i have to > bother / ask someone else? (-;) Sorry ,what second freeze? The backtraces you mention in comment 18 are not a freeze.
Ok thank you. From comment 18, if i'd enabled the password- screen-locker (light-locker ?) again, and right after the second i put the password in (about the Time 12:24:xx) These error logs came. after ea second freeze. Apr 26 12:24:28 lightdm[1041]: gkr-pam: unable to locate daemon control file Apr 26 12:24:31 systemd-coredump[1053]: Process 682 (xfwm4) of ... 1000 dumped core. Stack trace of thread 682: #0 0x00007f74f7e14186 n/a (libglib-2.0.so.0) ....and so on..... There is still some undeterministic system freezing. (But to be honest i lost track since i have now also nouveou system freezes (-; ) I'll report back if there is still any related xfce problem or not. LF
Hi, unlocking the screen-locker gave this of xfwm4. What can i do next? LF Apr 29 18:17:07 lightdm[9653]: gkr-pam: unable to locate daemon control file Apr 29 18:17:11 systemd-coredump[9659]: Process 690 (xfwm4) of user 1000 dumped core. Stack trace of thread 690: #0 0x00007fd8ed314186 n/a (libglib-2.0.so.0) #1 0x00007fd8ed311f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007fd8ed308a49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007fd8ed310f0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007fd8ed66d54e n/a (libgdk-3.so.0) #5 0x00007fd8ed67a6e5 n/a (libgdk-3.so.0) #6 0x00007fd8ecf9552a _XError (libX11.so.6) #7 0x00007fd8ecf923f8 n/a (libX11.so.6) #8 0x00007fd8ecf924a5 n/a (libX11.so.6) #9 0x00007fd8ecf93410 _XReply (libX11.so.6) #10 0x00007fd8ede36742 XIQueryDevice (libXi.so.6) #11 0x00007fd8ed66a1bd n/a (libgdk-3.so.0) #12 0x00007fd8ed67536d n/a (libgdk-3.so.0) #13 0x00007fd8ed674e36 n/a (libgdk-3.so.0) #14 0x00007fd8ed63dea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007fd8ed674aa4 n/a (libgdk-3.so.0) #16 0x00007fd8ed31a7bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007fd8ed31c739 n/a (libglib-2.0.so.0) #18 0x00007fd8ed31d6d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007fd8ed945e6f gtk_main (libgtk-3.so.0) #20 0x00005591c54a3765 n/a (xfwm4) #21 0x00007fd8eca44ce3 __libc_start_main (libc.so.6) #22 0x00005591c54a395e n/a (xfwm4) Stack trace of thread 699: #0 0x00007fd8ecb110d1 __poll (libc.so.6) #1 0x00007fd8ed31c690 n/a (libglib-2.0.so.0) #2 0x00007fd8ed31c77e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fd8ed31c7d2 n/a (libglib-2.0.so.0) #4 0x00007fd8ed2f7c21 n/a (libglib-2.0.so.0) #5 0x00007fd8ecbeda92 start_thread (libpthread.so.0) #6 0x00007fd8ecb1bcd3 __clone (libc.so.6) Stack trace of thread 700: #0 0x00007fd8ecb110d1 __poll (libc.so.6) #1 0x00007fd8ed31c690 n/a (libglib-2.0.so.0) #2 0x00007fd8ed31d6d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fd8ec428568 n/a (libgio-2.0.so.0) #4 0x00007fd8ed2f7c21 n/a (libglib-2.0.so.0) #5 0x00007fd8ecbeda92 start_thread (libpthread.so.0) #6 0x00007fd8ecb1bcd3 __clone (libc.so.6)
e.g. https://github.com/the-cavalry/light-locker/issues/139
(In reply to Linuxfreak from comment #30) Sorry, this was missing: Stack trace of thread 700: #0 0x00007fd8ecb110d1 __poll (libc.so.6) #1 0x00007fd8ed31c690 n/a (libglib-2.0.so.0) #2 0x00007fd8ed31d6d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fd8ec428568 n/a (libgio-2.0.so.0) #4 0x00007fd8ed2f7c21 n/a (libglib-2.0.so.0) #5 0x00007fd8ecbeda92 start_thread (libpthread.so.0) #6 0x00007fd8ecb1bcd3 __clone (libc.so.6) Stack trace of thread 841: #0 0x00007fd8ecbf3bac pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fd8e88471e4 n/a (nouveau_dri.so) #2 0x00007fd8e8846f08 n/a (nouveau_dri.so) #3 0x00007fd8ecbeda92 start_thread (libpthread.so.0) #4 0x00007fd8ecb1bcd3 __clone (libc.so.6) -- Subject: Speicherabbild für Prozess 690 (@COREDUMP_COMM) generiert -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Prozess 690 (xfwm4) ist abgebrochen worden und -- ein Speicherabbild wurde generiert. -- -- Üblicherweise ist dies ein Hinweis auf einen Programmfehler und sollte -- als Fehler dem jeweiligen Hersteller gemeldet werden.
(In reply to Linuxfreak from comment #30) > > Apr 29 18:17:07 lightdm[9653]: gkr-pam: unable to locate daemon control file > Apr 29 18:17:11 systemd-coredump[9659]: Process 690 (xfwm4) of user 1000 > dumped core. I've seen that stacktrace before, but it is entirely in gtk+ and the result of an XError, I am not sure how that would relate to xfwm4.
(In reply to Olivier Fourdan from comment #33) > (In reply to Linuxfreak from comment #30) > > > > Apr 29 18:17:07 lightdm[9653]: gkr-pam: unable to locate daemon control file > > Apr 29 18:17:11 systemd-coredump[9659]: Process 690 (xfwm4) of user 1000 > > dumped core. > > I've seen that stacktrace before, but it is entirely in gtk+ and the result > of an XError, I am not sure how that would relate to xfwm4. ok thank you Oliver, i'll put it here: https://github.com/CanonicalLtd/lightdm/issues/70
Nope, not lightdm, if anything that would be gtk...
(In reply to Olivier Fourdan from comment #35) > Nope, not lightdm, if anything that would be gtk... Thank you again. I am still learning, how the components work together... (-;
Well, looks like the crash is in gtk but could be related to xfwm4, or rather, the delay induced by the vblank sync. That still needs investigation, but again, that would be a different issue.
Just to add a data point, on Intel HD Graphics 5500 with X.org 1.20.5 (intel driver), kernel 5.1.7 and mesa 19.0.6, the glx method adds a massive update delay compared to the xpresent method. So it looks like when xpresent works, it works great.
This bug should be closed actually, my bad... GLX support is much smoother now in master than it was in 4.13.3. As for Xpresent, this is not xfwm4 fault - On Intel, Xpresent is broken due to the recently (xserver-1.20) added support for modifiers. See: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/193