Created attachment 1738674 [details] gdm debug log Description of problem: After user log in gdm start using 100% cpu from 1 core. Version-Release number of selected component (if applicable): 3.38.1 3.38.2 How reproducible: I am not sure. But it is confirmed on 2 different hardware. It is not clear to me if it bug, configuration or hardware. Steps to Reproduce: 1. Install Fedora 33 on aarch64 2. Log in user 3. Check cpu use Actual results: gdm use 1 core 100% or more Expected results: gdm should be low on cpu after log in is finished Additional info: * I have tried both X11 and Wayland - same result. * Tried to disable gdm and start gnome session with startx or "XDG_SESSION_TYPE=wayland dbus-run-session gnome-session" - system behave normal. strace show gdm do a lot of ppoll - I have not been able to find out for what. # strace -p 1025 strace: Process 1025 attached ppoll([{fd=7, events=POLLIN}, {fd=10, events=POLLPRI}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}], 6, {tv_sec=0, tv_nsec=0}, NULL, 0) = 0 (Timeout) # strace -c -fp 1025 strace: Process 1025 attached with 3 threads ^Cstrace: Process 1025 detached strace: Process 1029 detached strace: Process 1034 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 15.112729 9 1525886 ppoll ------ ----------- ----------- --------- --------- ---------------- 100.00 15.112729 9 1525886 total # gdb --pid=1021 GNU gdb (GDB) Fedora 10.1-2.fc33 Attaching to process 1021 [New LWP 1029] [New LWP 1034] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x0000ffff9b3fb5c0 in __GI___poll (fds=0xaaaad618d2c0, nfds=6, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41 41 return SYSCALL_CANCEL (ppoll, fds, nfds, timeout_ts_p, NULL, 0); (gdb) bt #0 0x0000ffff9b3fb5c0 in __GI___poll (fds=0xaaaad618d2c0, nfds=6, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41 #1 0x0000ffff9b8747d0 in g_main_context_poll (priority=<optimized out>, n_fds=6, fds=0xaaaad618d2c0, timeout=<optimized out>, context=0xaaaad6132b10) at ../glib/gmain.c:4422 #2 g_main_context_iterate.constprop.0 (context=0xaaaad6132b10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4114 #3 0x0000ffff9b81df80 in g_main_loop_run (loop=0xaaaad6141710) at ../glib/gmain.c:4317 #4 0x0000aaaac4581ec8 in main (argc=<optimized out>, argv=<optimized out>) at ../daemon/main.c:395 (gdb) t apply all bt Thread 3 (Thread 0xffff87ffeff0 (LWP 1034) "gdbus"): #0 0x0000ffff9b3fb5c0 in __GI___poll (fds=0xffff8000ccd0, nfds=3, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41 #1 0x0000ffff9b8747d0 in g_main_context_poll (priority=<optimized out>, n_fds=3, fds=0xffff8000ccd0, timeout=<optimized out>, context=0xaaaad613b060) at ../glib/gmain.c:4422 #2 g_main_context_iterate.constprop.0 (context=0xaaaad613b060, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4114 #3 0x0000ffff9b81df80 in g_main_loop_run (loop=0xaaaad613b150) at ../glib/gmain.c:4317 #4 0x0000ffff9b6ec298 in gdbus_shared_thread_func (user_data=0xaaaad613b030) at ../gio/gdbusprivate.c:280 #5 0x0000ffff9b84e498 in g_thread_proxy (data=0xaaaad612a180) at ../glib/gthread.c:820 #6 0x0000ffff9b0e40c8 in start_thread (arg=0x0) at pthread_create.c:463 #7 0x0000ffff9b405d1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78 Thread 2 (Thread 0xffff8c8b5ff0 (LWP 1029) "gmain"): #0 0x0000ffff9b3fb5c0 in __GI___poll (fds=0xaaaad6127560, nfds=1, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41 #1 0x0000ffff9b8747d0 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0xaaaad6127560, timeout=<optimized out>, context=0xaaaad6129390) at ../glib/gmain.c:4422 #2 g_main_context_iterate.constprop.0 (context=context@entry=0xaaaad6129390, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4114 #3 0x0000ffff9b81b80c in g_main_context_iteration (context=0xaaaad6129390, may_block=may_block@entry=1) at ../glib/gmain.c:4184 #4 0x0000ffff9b81d704 in glib_worker_main (data=<optimized out>) at ../glib/gmain.c:6077 #5 0x0000ffff9b84e498 in g_thread_proxy (data=0xaaaad610fea0) at ../glib/gthread.c:820 #6 0x0000ffff9b0e40c8 in start_thread (arg=0x0) at pthread_create.c:463 #7 0x0000ffff9b405d1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78 Thread 1 (Thread 0xffff9ad7b010 (LWP 1021) "gdm"): #0 0x0000ffff9b3fb5c0 in __GI___poll (fds=0xaaaad618d2c0, nfds=6, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41 #1 0x0000ffff9b8747d0 in g_main_context_poll (priority=<optimized out>, n_fds=6, fds=0xaaaad618d2c0, timeout=<optimized out>, context=0xaaaad6132b10) at ../glib/gmain.c:4422 #2 g_main_context_iterate.constprop.0 (context=0xaaaad6132b10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4114 #3 0x0000ffff9b81df80 in g_main_loop_run (loop=0xaaaad6141710) at ../glib/gmain.c:4317 #4 0x0000aaaac4581ec8 in main (argc=<optimized out>, argv=<optimized out>) at ../daemon/main.c:395 * I turned on gdm debug - attach the log.
I can reproduce this issue on two different AArch64 SBCs (Pine64 and a RK3399-based one).
I am also seeing gdm sitting at 100% CPU when running Fedora 33 as a Parallels guest on an Apple M1 host, so I think it's safe to say it's not hardware-dependent.
I'm seeing something similar on a Raspberry Pi 3b+. Are you also seeing a lot of: fedora audit[859]: AVC avc: denied { watch } for pid=859 comm="gmain" path="/etc/gdm" dev="mmcblk0p3" ino=100830 scontext=system_u:system_r:accountsd_t:s0tcontext=system_u:object_r:xdm_etc_t:s0 tclass=dir permissive=0 in the journal?
(In reply to Brandon Nielsen from comment #3) > I'm seeing something similar on a Raspberry Pi 3b+. > > Are you also seeing a lot of: > > fedora audit[859]: AVC avc: denied { watch } for pid=859 comm="gmain" > path="/etc/gdm" dev="mmcblk0p3" ino=100830 > scontext=system_u:system_r:accountsd_t:s0tcontext=system_u:object_r: > xdm_etc_t:s0 tclass=dir permissive=0 > > in the journal? I do not have my F33 system now to check. But I have tried to set selinux to permessive and disabled with no change. So I think you can rule out this message for the issue.
(In reply to bengt from comment #4) > (In reply to Brandon Nielsen from comment #3) > > I'm seeing something similar on a Raspberry Pi 3b+. > > > > Are you also seeing a lot of: > > > > fedora audit[859]: AVC avc: denied { watch } for pid=859 comm="gmain" > > path="/etc/gdm" dev="mmcblk0p3" ino=100830 > > scontext=system_u:system_r:accountsd_t:s0tcontext=system_u:object_r: > > xdm_etc_t:s0 tclass=dir permissive=0 > > > > in the journal? > > I do not have my F33 system now to check. But I have tried to set selinux to > permessive and disabled with no change. So I think you can rule out this > message for the issue. I was wondering if it was somehow related to bug 1928565, apparently not. Thank you for following up.
I have tested fresh install Fedora 34. gdm-40-rc.1 give same result. gdm hold one cpu core 100% or more. Please ask for more details for finding the error.
I have tried to downgrade gdm. With this version https://kojipkgs.fedoraproject.org//packages/gdm/3.37.90/2.fc34/aarch64/gdm-3.37.90-2.fc34.aarch64.rpm gdm works as expected. Log in user and process go down to 0% cpu. This issue was introduced from version 3.37.90-2 and 3.38 and is still in current version 40.rc-1
Fixed in latest buil in testing: https://kojipkgs.fedoraproject.org//packages/gdm/3.38.2.1/3.fc33/aarch64/gdm-3.38.2.1-3.fc33.aarch64.rpm