Bug 1907150 - Fedora 33/34 aarch64 gdm use 100% cpu from 1 core
Summary: Fedora 33/34 aarch64 gdm use 100% cpu from 1 core
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 34
Hardware: aarch64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-13 10:29 UTC by bengt
Modified: 2021-04-04 15:44 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-04 15:44:21 UTC
Type: Bug


Attachments (Terms of Use)
gdm debug log (38.43 KB, text/plain)
2020-12-13 10:29 UTC, bengt
no flags Details

Description bengt 2020-12-13 10:29:03 UTC
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.

Comment 1 Christoph Müllner 2020-12-25 22:13:14 UTC
I can reproduce this issue on two different AArch64 SBCs (Pine64 and a RK3399-based one).

Comment 2 wjbarton 2021-02-19 01:50:32 UTC
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.

Comment 3 Brandon Nielsen 2021-02-19 20:26:13 UTC
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?

Comment 4 bengt 2021-02-20 11:36:03 UTC
(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.

Comment 5 Brandon Nielsen 2021-02-23 00:57:28 UTC
(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.

Comment 6 bengt 2021-03-20 20:30:50 UTC
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.

Comment 7 bengt 2021-03-22 14:08:01 UTC
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


Note You need to log in before you can comment on or make changes to this bug.