Created attachment 577541 [details] Attached is output of strace of gnome-shell process that has the high CPU: strace -p 1671 Description of problem: With only a web browser open, and little activity, gnome-shell is constantly using > 100% CPU (as shown by top). Version-Release number of selected component (if applicable): gnome-shell-3.4.0-1.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot the system 2. Open Chrome 3. Actual results: gnome-shell uses > 100% CPU Expected results: gnome-shell doesn't hog the system Additional info: uptime 10:07:25 up 11 min, 2 users, load average: 1.75, 1.48, 1.00 ps aux [root@e6510 anthony]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.1 0.0 41660 4472 ? Ss 09:55 0:01 /usr/lib/systemd/systemd root 2 0.0 0.0 0 0 ? S 09:55 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 09:55 0:00 [ksoftirqd/0] root 6 0.0 0.0 0 0 ? S 09:55 0:00 [migration/0] root 7 0.0 0.0 0 0 ? S 09:55 0:00 [watchdog/0] root 8 0.0 0.0 0 0 ? S 09:55 0:00 [migration/1] root 10 0.0 0.0 0 0 ? S 09:55 0:00 [ksoftirqd/1] root 11 0.0 0.0 0 0 ? S 09:55 0:00 [kworker/0:1] root 12 0.0 0.0 0 0 ? S 09:55 0:00 [watchdog/1] root 13 0.0 0.0 0 0 ? S 09:55 0:00 [migration/2] root 15 0.0 0.0 0 0 ? S 09:55 0:00 [ksoftirqd/2] root 16 0.0 0.0 0 0 ? S 09:55 0:00 [watchdog/2] root 17 0.0 0.0 0 0 ? S 09:55 0:00 [migration/3] root 19 0.0 0.0 0 0 ? S 09:55 0:00 [ksoftirqd/3] root 20 0.0 0.0 0 0 ? S 09:55 0:00 [watchdog/3] root 21 0.0 0.0 0 0 ? S< 09:55 0:00 [cpuset] root 22 0.0 0.0 0 0 ? S< 09:55 0:00 [khelper] root 23 0.0 0.0 0 0 ? S 09:55 0:00 [kdevtmpfs] root 24 0.0 0.0 0 0 ? S< 09:55 0:00 [netns] root 25 0.0 0.0 0 0 ? S 09:55 0:00 [sync_supers] root 26 0.0 0.0 0 0 ? S 09:55 0:00 [bdi-default] root 27 0.0 0.0 0 0 ? S< 09:55 0:00 [kintegrityd] root 28 0.0 0.0 0 0 ? S< 09:55 0:00 [kblockd] root 29 0.0 0.0 0 0 ? S< 09:55 0:00 [ata_sff] root 30 0.0 0.0 0 0 ? S 09:55 0:00 [khubd] root 31 0.0 0.0 0 0 ? S< 09:55 0:00 [md] root 32 0.1 0.0 0 0 ? S 09:55 0:01 [kworker/1:1] root 34 0.0 0.0 0 0 ? S 09:55 0:00 [kswapd0] root 35 0.0 0.0 0 0 ? SN 09:55 0:00 [ksmd] root 36 0.0 0.0 0 0 ? SN 09:55 0:00 [khugepaged] root 37 0.0 0.0 0 0 ? S 09:55 0:00 [fsnotify_mark] root 38 0.0 0.0 0 0 ? S< 09:55 0:00 [crypto] root 44 0.0 0.0 0 0 ? S< 09:55 0:00 [kthrotld] root 47 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_0] root 48 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_1] root 49 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_2] root 50 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_3] root 51 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_4] root 52 0.0 0.0 0 0 ? S 09:55 0:00 [scsi_eh_5] root 55 0.0 0.0 0 0 ? S 09:55 0:00 [kworker/u:4] root 56 0.0 0.0 0 0 ? S 09:55 0:00 [kworker/u:5] root 57 0.0 0.0 0 0 ? S 09:55 0:00 [kworker/u:6] root 58 0.1 0.0 0 0 ? S 09:55 0:00 [kworker/0:2] root 59 0.0 0.0 0 0 ? S< 09:55 0:00 [kpsmoused] root 61 0.1 0.0 0 0 ? S 09:55 0:01 [kworker/2:1] root 155 0.0 0.0 0 0 ? S 09:55 0:00 [kworker/1:2] root 208 0.2 0.0 0 0 ? S 09:55 0:01 [kworker/3:2] root 225 0.0 0.0 0 0 ? S< 09:55 0:00 [firewire] root 246 0.0 0.0 0 0 ? S 09:55 0:00 [pccardd] root 279 0.0 0.0 0 0 ? S 09:55 0:00 [jbd2/sda3-8] root 280 0.0 0.0 0 0 ? S< 09:55 0:00 [ext4-dio-unwrit] root 312 0.0 0.0 30788 1572 ? Ss 09:55 0:00 /usr/lib/systemd/systemd-journald root 313 0.0 0.0 0 0 ? S 09:55 0:00 [kauditd] root 319 0.0 0.0 27960 2512 ? Ss 09:55 0:00 /usr/lib/udev/udevd root 353 0.0 0.0 0 0 ? S< 09:55 0:00 [kvm-irqfd-clean] root 356 0.0 0.0 0 0 ? S 09:55 0:00 [flush-8:0] root 473 0.0 0.0 0 0 ? S 09:55 0:00 [ips-adjust] root 474 0.0 0.0 0 0 ? S 09:55 0:00 [ips-monitor] root 485 0.0 0.0 0 0 ? S< 09:55 0:00 [cfg80211] root 488 0.0 0.0 0 0 ? S< 09:55 0:00 [iwlwifi] root 505 0.2 0.0 0 0 ? S 09:55 0:01 [kworker/2:2] root 509 0.0 0.0 0 0 ? S< 09:55 0:00 [hd-audio0] root 519 0.0 0.0 0 0 ? S< 09:55 0:00 [hci0] root 586 0.0 0.0 0 0 ? S 09:56 0:00 [jbd2/sda2-8] root 587 0.0 0.0 0 0 ? S< 09:56 0:00 [ext4-dio-unwrit] root 593 0.0 0.0 0 0 ? S 09:56 0:00 [jbd2/sda5-8] root 594 0.0 0.0 0 0 ? S< 09:56 0:00 [ext4-dio-unwrit] root 604 0.0 0.0 21040 2132 ? Ss 09:56 0:00 /usr/sbin/bluetoothd -n root 610 0.0 0.0 26204 1084 ? S<sl 09:56 0:00 /sbin/auditd -n root 625 0.0 0.0 80172 824 ? S<sl 09:56 0:00 /sbin/audispd root 629 0.0 0.0 21420 868 ? S< 09:56 0:00 /usr/sbin/sedispatch root 650 0.0 0.1 364816 7428 ? Ssl 09:56 0:00 /usr/sbin/NetworkManager --no-daemon root 657 0.0 0.0 122732 1236 ? Ss 09:56 0:00 /usr/sbin/abrtd -d -s avahi 666 0.0 0.0 28008 1704 ? Ss 09:56 0:00 avahi-daemon: running [e6510.local] root 667 0.0 0.0 21064 528 ? Ss 09:56 0:00 /usr/sbin/irqbalance avahi 670 0.0 0.0 27880 236 ? S 09:56 0:00 avahi-daemon: chroot helper root 671 0.0 0.0 16944 800 ? Ss 09:56 0:00 /usr/sbin/atd -f root 672 0.0 0.0 11564 312 ? Ss 09:56 0:00 /usr/bin/system-setup-keyboard root 676 0.0 0.0 26152 1368 ? Ss 09:56 0:00 /usr/lib/systemd/systemd-logind root 679 0.0 0.0 6436 852 ? Ss 09:56 0:00 /usr/sbin/mcelog --ignorenodev --daemon --foreground chrony 683 0.0 0.0 24540 1264 ? S 09:56 0:00 /usr/sbin/chronyd -u chrony dbus 686 0.0 0.0 22728 2432 ? Ss 09:56 0:00 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activati root 688 0.0 0.0 118388 1436 ? Ss 09:56 0:00 /usr/sbin/crond -n root 695 0.0 0.0 114192 824 ? S 09:56 0:00 /bin/bash /usr/sbin/ksmtuned root 702 0.0 0.0 251500 3744 ? Ssl 09:56 0:00 /sbin/rsyslogd -n -c 5 root 705 0.0 0.0 220380 5184 ? Sl 09:56 0:00 /usr/libexec/polkit-1/polkitd --no-debug root 715 0.0 0.0 0 0 ? S< 09:56 0:00 [iscsi_eh] root 717 0.0 0.0 0 0 ? S< 09:56 0:00 [ib_mcast] root 718 0.0 0.0 0 0 ? S< 09:56 0:00 [ib_cm] root 719 0.0 0.0 0 0 ? S< 09:56 0:00 [iw_cm_wq] root 720 0.0 0.0 0 0 ? S< 09:56 0:00 [ib_addr] root 721 0.0 0.0 0 0 ? S< 09:56 0:00 [rdma_cm] root 727 0.0 0.0 0 0 ? S< 09:56 0:00 [krfcommd] root 728 0.0 0.0 0 0 ? S< 09:56 0:00 [cnic_wq] root 729 0.0 0.0 0 0 ? S< 09:56 0:00 [bnx2i_thread/0] root 730 0.0 0.0 0 0 ? S< 09:56 0:00 [bnx2i_thread/1] root 731 0.0 0.0 0 0 ? S< 09:56 0:00 [bnx2i_thread/2] root 732 0.0 0.0 0 0 ? S< 09:56 0:00 [bnx2i_thread/3] root 735 0.0 0.0 69020 2652 ? S 09:56 0:00 /usr/sbin/modem-manager root 737 0.0 0.0 16368 1292 ? Ss 09:56 0:00 /usr/sbin/lldpad root 742 0.0 0.0 22764 924 ? Ss 09:56 0:00 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid root 744 0.0 0.0 98784 328 ? Ssl 09:56 0:00 iscsiuio root 749 0.0 0.0 19160 896 ? Ss 09:56 0:00 /sbin/rpcbind -w root 751 0.0 0.0 0 0 ? S< 09:56 0:00 [fc_exch_workque] root 752 0.0 0.0 0 0 ? S< 09:56 0:00 [fc_rport_eq] root 756 0.0 0.0 5052 440 ? Ss 09:56 0:00 iscsid root 757 0.0 0.0 7948 3864 ? S<Ls 09:56 0:00 iscsid root 762 0.0 0.0 0 0 ? S< 09:56 0:00 [rpciod] rpcuser 765 0.0 0.0 23532 1372 ? Ss 09:56 0:00 /sbin/rpc.statd root 770 0.0 0.0 0 0 ? S< 09:56 0:00 [fcoethread/0] root 771 0.0 0.0 0 0 ? S< 09:56 0:00 [fcoethread/1] root 772 0.0 0.0 0 0 ? S< 09:56 0:00 [fcoethread/2] root 773 0.0 0.0 0 0 ? S< 09:56 0:00 [fcoethread/3] root 776 0.0 0.0 8540 348 ? Ss 09:56 0:00 /usr/sbin/fcoemon --syslog root 797 0.0 0.0 49504 1976 ? Ss 09:56 0:00 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B - root 881 0.0 0.0 117220 756 ? Ssl 09:56 0:00 /usr/lib/vmware/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,defaul root 926 0.0 0.0 4720 468 ? Ss 09:56 0:00 /usr/bin/vmnet-bridge -s 6 -d /var/run/vmnet-bridge-0.pid -n 0 root 934 0.0 0.0 4692 172 ? Ss 09:56 0:00 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet1.pid /dev/vm root 939 0.0 0.0 13820 336 ? Ss 09:56 0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /e root 942 0.0 0.0 11640 1060 ? S 09:56 0:00 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vm root 944 0.0 0.0 4692 172 ? Ss 09:56 0:00 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vm root 949 0.0 0.0 13820 336 ? Ss 09:56 0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /e root 961 0.0 0.0 23744 836 ? Ss 09:56 0:00 /usr/sbin/vmware-authdlauncher root 1011 0.0 0.0 23968 1780 ? Ss 09:56 0:00 /usr/bin/vmware-usbarbitrator root 1156 0.1 0.9 651084 55944 ? Sl 09:56 0:00 /usr/lib/vmware/bin/vmware-hostd -a /etc/vmware/hostd/config.xml root 1161 0.0 0.0 209680 2180 ? Ssl 09:56 0:00 /usr/sbin/gdm-binary -nodaemon root 1173 0.0 0.0 247468 4112 ? Sl 09:56 0:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Dis root 1180 15.1 0.3 135572 19176 tty1 Ss+ 09:56 1:45 /usr/bin/Xorg :0 -background none -logverbose 7 -auth /var/run/gdm/auth- root 1240 0.0 0.0 317780 4168 ? Ssl 09:56 0:00 /usr/libexec/accounts-daemon root 1263 0.0 0.0 226392 4124 ? Sl 09:56 0:00 /usr/libexec/upowerd root 1293 0.0 0.1 88796 7340 ? S 09:56 0:00 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run rtkit 1318 0.0 0.0 164560 1224 ? SNsl 09:56 0:00 /usr/libexec/rtkit-daemon root 1338 0.0 0.0 350484 4472 ? Sl 09:56 0:00 gdm-session-worker [pam/gdm-password] root 1372 0.0 0.0 0 0 ? S 09:56 0:00 [scsi_eh_6] root 1373 0.0 0.0 0 0 ? S< 09:56 0:00 [iscsi_q_6] root 1374 0.0 0.0 0 0 ? S< 09:56 0:00 [scsi_wq_6] root 1382 0.0 0.0 27956 1768 ? S 09:56 0:00 /usr/lib/udev/udevd root 1399 0.0 0.0 97648 2224 ? Ss 09:56 0:00 sendmail: accepting connections smmsp 1430 0.0 0.0 82700 1796 ? Ss 09:56 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue anthony 1436 0.0 0.1 461616 7152 ? SLl 09:56 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login anthony 1440 0.0 0.2 508736 13160 ? Ssl 09:56 0:00 gnome-session anthony 1457 0.0 0.0 20212 504 ? S 09:56 0:00 dbus-launch --sh-syntax --exit-with-session anthony 1458 0.1 0.0 23708 2240 ? Ss 09:56 0:01 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session anthony 1519 0.0 0.0 322464 4584 ? Sl 09:56 0:00 /usr/libexec/imsettings-daemon anthony 1522 0.0 0.0 159032 2160 ? S 09:56 0:00 /usr/libexec/gvfsd anthony 1524 0.0 0.0 285084 3224 ? Sl 09:56 0:00 /usr/libexec//gvfs-fuse-daemon -f /home/anthony/.gvfs anthony 1616 0.1 0.3 892072 18296 ? Sl 09:56 0:00 /usr/libexec/gnome-settings-daemon anthony 1625 0.0 0.1 410980 10252 ? Sl 09:56 0:00 /usr/bin/pulseaudio --start anthony 1632 0.0 0.0 102892 2476 ? S 09:56 0:00 /usr/libexec/pulse/gconf-helper anthony 1634 0.0 0.0 137320 3300 ? S 09:56 0:00 /usr/libexec/gconfd-2 root 1639 0.0 0.0 208932 4436 ? Ss 09:56 0:00 /usr/sbin/cupsd -f colord 1640 0.0 0.0 327312 5172 ? Ssl 09:56 0:00 /usr/libexec/colord colord 1643 0.0 0.1 493044 7620 ? Ssl 09:56 0:00 /usr/libexec/colord-sane anthony 1647 0.0 0.0 465728 4132 ? Sl 09:56 0:00 /usr/libexec/gsd-printer anthony 1652 0.0 0.0 242524 5008 ? Sl 09:56 0:00 /usr/libexec/gvfs-udisks2-volume-monitor root 1654 0.0 0.0 369780 5168 ? Ssl 09:56 0:00 /usr/lib/udisks2/udisksd --no-debug anthony 1660 0.0 0.0 241732 1848 ? Sl 09:56 0:00 /usr/libexec/gvfs-afc-volume-monitor anthony 1663 0.0 0.0 167656 2120 ? S 09:56 0:00 /usr/libexec/gvfs-gphoto2-volume-monitor anthony 1671 104 2.9 1810676 175632 ? Sl 09:56 11:52 /usr/bin/gnome-shell anthony 1680 0.0 0.2 564624 15264 ? Sl 09:56 0:00 nm-applet anthony 1681 0.0 0.1 430208 10144 ? Sl 09:56 0:00 gnome-screensaver anthony 1684 3.7 0.3 494456 21752 ? Sl 09:56 0:25 /usr/libexec/tracker-store anthony 1687 0.0 0.2 552040 14644 ? Sl 09:56 0:00 /usr/libexec/evolution/3.4/evolution-alarm-notify anthony 1688 0.0 0.1 420604 8504 ? Sl 09:56 0:00 zeitgeist-datahub anthony 1689 0.0 0.0 296100 4352 ? Sl 09:56 0:00 /usr/libexec/deja-dup/deja-dup-monitor anthony 1690 3.4 2.9 1198344 178712 ? SNl 09:56 0:23 /usr/libexec/tracker-miner-fs anthony 1692 0.0 0.0 112088 1272 ? S 09:56 0:00 /bin/sh /usr/bin/gnome-do anthony 1700 0.1 0.5 725800 34788 ? Sl 09:56 0:00 mono /usr/lib64/gnome-do/Do.exe anthony 1706 0.0 0.2 266092 16560 ? S 09:56 0:00 /usr/bin/python /usr/bin/zeitgeist-daemon anthony 1710 0.0 0.0 255760 2492 ? Sl 09:56 0:00 /usr/libexec/dconf-service anthony 1770 0.0 0.2 771404 12468 ? Sl 09:56 0:00 /usr/libexec/evolution-calendar-factory anthony 1781 0.0 0.1 333104 6072 ? Sl 09:56 0:00 /usr/libexec/gnome-shell-calendar-server anthony 1785 0.0 0.1 342084 6700 ? Sl 09:56 0:00 /usr/libexec/mission-control-5 anthony 1789 0.0 0.2 415616 13240 ? Sl 09:56 0:00 /usr/libexec/goa-daemon anthony 1826 0.1 0.2 393060 15880 ? Sl 09:56 0:00 /usr/libexec/libsocialweb-core anthony 1836 0.5 0.2 666768 16892 ? Sl 09:56 0:03 gnome-terminal anthony 1842 0.0 0.0 8412 696 ? S 09:56 0:00 gnome-pty-helper anthony 1843 0.0 0.0 115644 3336 pts/0 Ss 09:56 0:00 bash root 1954 0.0 0.0 149232 1732 pts/0 S 09:56 0:00 su root 1958 0.0 0.0 115652 3352 pts/0 S 09:56 0:00 bash anthony 2041 6.0 1.8 775676 112584 ? SLl 09:57 0:39 /opt/google/chrome/chrome anthony 2046 0.0 0.1 344568 6216 ? S 09:57 0:00 /opt/google/chrome/chrome anthony 2048 0.0 0.0 6416 288 ? S 09:57 0:00 /opt/google/chrome/chrome-sandbox /opt/google/chrome/chrome --type=zygot root 2049 0.0 0.0 27956 1724 ? S 09:57 0:00 /usr/lib/udev/udevd anthony 2050 0.0 0.2 363304 16472 ? S 09:57 0:00 /opt/google/chrome/chrome --type=zygote root 2051 0.0 0.0 0 0 ? Z 09:57 0:00 [chrome-sandbox] <defunct> anthony 2053 0.0 0.0 106592 3812 ? S 09:57 0:00 /opt/google/chrome/nacl_helper_bootstrap /opt/google/chrome/nacl_helper anthony 2082 0.0 0.4 957216 27456 ? Sl 09:57 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2086 1.3 0.8 980324 53604 ? Sl 09:57 0:08 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2090 0.1 0.6 956332 36356 ? Sl 09:57 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2094 0.0 0.5 951212 32044 ? Sl 09:57 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2120 1.1 2.2 1095784 137484 ? Sl 09:57 0:07 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2131 0.0 0.6 958800 39868 ? Sl 09:57 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2139 0.1 0.9 977672 55040 ? Sl 09:57 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2147 9.0 3.4 1180020 210872 ? Sl 09:57 0:58 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2154 0.6 1.3 1040420 82688 ? Sl 09:57 0:04 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2161 0.2 1.0 986732 63176 ? Sl 09:57 0:01 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest anthony 2239 0.7 0.5 493920 35708 ? Sl 09:57 0:04 /opt/google/chrome/chrome --type=plugin --plugin-path=/usr/lib64/flash-p anthony 3440 0.0 0.3 375940 18544 ? Sl 10:00 0:00 /opt/google/chrome/chrome --type=plugin --plugin-path=/opt/google/talkpl anthony 3443 0.0 0.1 396096 11816 ? Sl 10:00 0:00 /opt/google/talkplugin/GoogleTalkPlugin root 3502 0.0 0.0 0 0 ? S 10:01 0:00 [kworker/3:0] anthony 3513 4.4 2.2 1021952 134732 ? Sl 10:01 0:16 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest root 3557 0.1 0.0 0 0 ? S 10:06 0:00 [kworker/3:1] root 3565 0.0 0.0 106844 504 ? S 10:07 0:00 sleep 60 root 3570 0.0 0.0 115736 1192 pts/0 R+ 10:07 0:00 ps aux Attached is output of strace of gnome-shell process that has the high CPU: strace -p 1671
I have started seeing (presumably) the same problem after rebooting my updated f17 system. Downgrading (ie removing everything from -testing) didn't make the problem go away. I have not been able to reproduce the system on another machine.
Honestly, I wasn't expecting the strace to show anything useful - it generally doesn't for a GUI program, but there's actually a smoking gun in it: inotify_add_watch(19, "/home/anthony/.config/menus/gnomecc-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) inotify_add_watch(19, "/etc/xdg/menus/gnomecc-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) inotify_add_watch(19, "/home/anthony/.config/menus/applications-gnome-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) inotify_add_watch(19, "/etc/xdg/menus/applications-gnome-merged", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) Occurs three times during the trace, presumably over a short period of time. So, for some reason, it's constantly re-adding file-changed monitors for menu files. As a first test, can you move .config/menus/ away to a different location and see if that makes a difference to the problem?
Created attachment 579580 [details] gnome shell strace It seems like moving .config/menus away made the problem even worse for me. Before it rarely went over 100% - now it do that most of the time. I have for example /proc/1826/fd/19 -> anon_inode:inotify and strace see for example almost 2000 continues lines like 16:21:08 read(19, "\25\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0l\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 1024) = 32 followed by a similar number of 16:21:08 gettimeofday({1335190868, 881922}, NULL) = 0 I don't know if that is what is eating cpu, but it seems suspicious.
Updating pam.d with systemd stuff as describe do Bug 815413 seems to have done that I no longer see the problem. That will however at most be a trigger; it is still be a bug in gnome-shell that wrong permissions can cause something to spin this way.
I'm seeing the same 100% (actually 222%) gnome-shell cpu usage and inotify calls in strace. I tried following Mads suggestion with authconfig but couldn't get it to reduce (was there a X restart in the middle ? just doing gnome-shell restarts via alt-F2+lg+r didn't work). Will be happy to provide any further information. $ rpm -q gnome-shell gnome-shell-3.4.1-4.fc17.x86_64 Alon
if you mkdir -p the directories that it says "No such file or directory" for does it settle down? Kind of reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=476938 (though we don't use gamin anymore)
(In reply to comment #5) > I tried following Mads suggestion with authconfig but > couldn't get it to reduce (was there a X restart in the middle ? just doing > gnome-shell restarts via alt-F2+lg+r didn't work). Yes, at least that. I would do a reboot after changing the pam config to make sure all components pick up the right and consistent configuration.
I'm also having this problem. Installed Fedora 16 as a virtual machine inside Virtualbox on a Windows 7 host a few days ago and upgraded to Fedora 17 today using preupgrade. The fixes in Bug 815413 didn't fix my issues, and I am fully up to date in yum with the patch to pam that was produced from that bugfix.
(In reply to comment #6) > if you mkdir -p the directories that it says "No such file or directory" for > does it settle down? > That results in 1) no more inotify calls 2) still large cpu usage, about the same. (it ranges 30%-120%) Attaching strace. > Kind of reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=476938 > (though we don't use gamin anymore) Doesn't look like the only problem since creating the directories didn't drop the cpu load.
Created attachment 589776 [details] strace after mkdir -p for inotify gnome-shell strace (on the first process that shows up with pgrep gnome-shell) that shows a lot of activity, after creating the missing directories for successfull inotify calls - two in /etc and two in $HOME/.config
I take it back, I rebooted and now I have no problems with gnome-shell, meaning cpu usage went down to normal, it's responsive as expected. Unfortunately I don't know what solved the problem :/ Just FYI restarting gnome-shell was not enough - i.e. running it under a separate "dbus-launch gnome-shell" while the previous session was still alive.
Grub still has an entry for 3.3.7-1.fc16.x86_64 for me, where gnome-shell runs at about 30-40% CPU. Unsure if that helps anybody. I've ran mkdir -p as suggested on those 4 directories (although I never saw that error pop up in my strace of gnome-shell), no difference. Unsure how to attach files here, so here's parts of a strace I did: http://p.sldr.us/raw/NEAsvoTl/ http://p.sldr.us/raw/7nH9wSpgqO gettimeofday() and read() are called A LOT
Oops hit submit too soon, here's the output from strace -fcp after a short run http://p.sldr.us/raw/YSnEAiOb
(In reply to comment #12) > Grub still has an entry for 3.3.7-1.fc16.x86_64 for me, where gnome-shell > runs at about 30-40% CPU. Unsure if that helps anybody. I guess that could be a part of the explanation. You are using an old initramfs that might be slightly incompatible with f17 systemd or file locations after usr-move. Please run something like grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg and reboot.
Well now grub just says Fedora and advanced Fedora (paraphrasing) and has a fancy boot animation... that's new. gnome-shell is still running high though, ~85% on all 3 cores. For the record, I was booting into the entry for 3.3.7-1.fc17.x86_64 every time except that once just to look at CPU usage there. Also a reminder that I'm running this in Virtualbox, so I can fusker with a few hardware settings if I need to.
Just did a fresh install of Fedora 17 and now I'm hitting the problem again. Must be a problem with Virtualbox Guest Additions interacting with it.
I upgraded an F16 system (real HW, not a VM) to F17, then did a "yum update", and had this problem, as well as sound problems. Tried stuff suggested here, didn't help. Did a fresh install of F17, was working fine, with only the usual Gnome Shell lossage, no excessive CPU. Then did a "yum update", and it's back to using >100% CPU again. Thought that possibly the 3.4.4 kernel might have something to do with this or my sound problems, so rebooted to 3.3.4, and that hasn't helped anything. So I think something in the other 419 packages that "yum update" updated is the culprit, but I don't know how to track it down without spending an insane amount of time on it.
I verified that after doing a "yum history undo" to roll back the previous "yum upgrade", so that I am back to the original F17 package set, Gnome Shell no longer sucks up >100% of the CPU. Something in the updates repository other than the kernel is responsible for breaking this.
I've tracked down which package update breaks this on my F17 system. When using systemd{,-sysv}-44-8, which was the original F17 version, Gnome Shell has reasonable CPU utilization. When upgraded to systemd{,-sysv}-44-17, the Gnome Shell CPU utilization goes through the roof. One difference between the two situations is that systemd-loginctl shows a user session when using 44-8: [eric@p1 ~]$ systemd-loginctl SESSION UID USER SEAT 2 1000 eric seat0 1 sessions listed. But no session when using 44-17: [eric@p1 ~]$ systemd-loginctl SESSION UID USER SEAT 0 sessions listed. I'd suggest that other people having this CPU utilization problem check their systemd-loginctl output, to see if they too are missing a session.
Session exists for me, I'm fully up-to-date according to Software Update. I've given this VM 3 cores and it looks like gnome-shell idles at a normal level with just terminal open and top running. If I open System Monitor, top reports gnome-shell instantly spiking to around 150% CPU and System Monitor shows the same. It floats around 120-150% until I close System Monitor. Launching other programs cause it to spike high every now and then, but nothing nearly as bad.
Since my problem apparently has a completely different root cause than that of other people with the CPU >100% problem, and mine has been isolated to a problem with systemd session creation, I have created bug #839736 to track my issue.
I had the same issue, but from the start I noticed it had first occurred during watching videos on youtube. After closing youtube, CPU-load would come down to "only" about 100-120%, after closing the browser (Firefox), it would come down to ~20-25% after a short while. This was enough to keep the fan running higher than normal, and the latter would only come down to normal (inaudible) levels after closing the System Monitor (sorry, I'm not much of an expert, I am helpless without graphical tools). ...all together, these seemed to indicate to me some software graphics rendering was causing the high CPU load (albeit the System Monitor reporting it for the "Gnome Shell" task). Even the animated "Resources" view in the System Monitor seemed to be enough to keep CPU at >20%. My laptop has a secondary Nvidia graphics card, so I decided to install the proprietary drivers instead of nouveau. - which seems to have solved the issue. System Monitor reports ~5% CPU load when idle now, and watching videos hardly raises it at all... Sorry I can't offer much information on the exact cause of the original problem, this is just a workaround with proprietary software. Dell Latitude e6420, Intel i7 2720QM, 16GB RAM, Graphics integrated Intel and a Nvidia NVS 4200M, freshly installed (and updated) Fedora 17 64Bit with Gnome 3.4.2 on a 3.5.4-1.fc17.x86_64 Kernel
This just started to happen in my laptop. Using fedora 18 up to date. Nombre : gnome-shell Arquitectura : x86_64 Versión : 3.6.1 Lanzamiento : 3.fc18 Tamaño : 4.6 M Repositorio : installed Desde el repositorio : updates-testing
Happens to me on F18 too; should we open a separate bug for it or discuss it on the same bug? systemd-195-5.fc18.x86_64 gnome-shell-3.6.1-3.fc18.x86_64 kernel-3.6.2-2.fc18.x86_64 kernel-3.6.3-3.fc18.x86_64 kernel-3.6.5-2.fc18.x86_64 xorg-x11-server-Xorg-1.13.0-7.fc18.x86_64 xorg-x11-drv-intel-2.20.12-1.fc18.x86_64 (problem occurs with both 3.6.3 and 3.6.5 kernels; trying going back to 3.6.2 next) In my case, systemd-loginctl shows one session, so it's not that problem. I freshly installed F17 a couple of weeks ago and immediately upgraded to F18 using yum (without even logging in to GNOME once) so it's not any leftover F17 cruft either. That certainly explains why my laptop would sometimes run out of battery completely if I only plug it in when it's down to 5% or so -- I get 40%-260+% CPU usage on a dual core + HT Core i5 ULV system, Intel graphics, with only a single tab of Chrome open and not using Flash.
Michel and javiermon, regarding the F18 issue: can you check what 'glxinfo | grep render' says? If it's using llvmpipe, you are likely hitting bug #870695.
(In reply to comment #25) > Michel and javiermon, regarding the F18 issue: can you check what 'glxinfo | > grep render' says? If it's using llvmpipe, you are likely hitting bug > #870695. Not using llvmpipe. Besides, given that llvmpipe is the only "fallback" option for GNOME 3.8, shouldn't we be worried if on a relatively recent laptop CPU consumption is still so high? $ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile GL_NV_conditional_render, GL_ARB_ES2_compatibility, GL_ARB_debug_output,
Hi In my case it was bug #870695. Now fixed with the upgrade and then running /usr/libexec/plymouth/plymouth-update-initrd Thanks,
That might have been my problem as well - with the Plymouth update (I didn't have to run update-initrd by hand) now gnome-shell takes < 1% CPU when idle.
Thanks, javiermon, that solved my problem too!.
Hi, with last update (kernel 3.7.3-101.fc17.x86_64 and gnome-shell-3.4.1-6) the problem appears again: [jota@jotadesk ~]$ top -b -d 5 | grep gnome-shell 1213 jota 20 0 1830m 206m 36m S 21.5 5.3 3:57.15 gnome-shell 2010 jota 20 0 1791m 101m 34m S 3.9 2.6 1:10.04 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1831m 207m 36m S 28.1 5.3 3:58.56 gnome-shell 2010 jota 20 0 1791m 101m 34m S 4.0 2.6 1:10.24 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1831m 207m 36m S 30.5 5.3 4:00.09 gnome-shell 2010 jota 20 0 1791m 101m 34m S 2.8 2.6 1:10.38 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1831m 207m 36m S 25.1 5.3 4:01.35 gnome-shell 2010 jota 20 0 1791m 101m 34m S 3.8 2.6 1:10.57 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1832m 209m 36m S 30.1 5.4 4:02.86 gnome-shell 2010 jota 20 0 1791m 101m 34m S 3.6 2.6 1:10.75 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1832m 209m 36m S 28.1 5.4 4:04.27 gnome-shell 2010 jota 20 0 1791m 101m 34m S 5.0 2.6 1:11.00 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal 1213 jota 20 0 1832m 209m 36m S 28.1 5.4 4:05.68 gnome-shell 2010 jota 20 0 1791m 101m 34m S 4.0 2.6 1:11.20 gnome-shell 1349 jota 20 0 537m 11m 7260 S 0.0 0.3 0:00.05 gnome-shell-cal 2141 jota 20 0 537m 9836 7260 S 0.0 0.2 0:00.05 gnome-shell-cal ... gnome-shell is always between 20% and 30% and sometimes higher 30% I have executed /usr/libexec/plymouth/plymouth-update-initrd with no results.
Same here on a fresh Fedora 18 install, plymoth is up to date, even tried the plymouth-update-initrd Also reportetd to: http://forums.fedoraforum.org/showthread.php?t=288526
(In reply to comment #31) > http://forums.fedoraforum.org/showthread.php?t=288526 I also see this symptom on a MacBookPro10,1 retina using nouveau.
Any hints? Funny enough my system is the same as Mads's. Mads's - did you try with nvidia drivers also?
(In reply to comment #33) > Mads's - did you try with nvidia drivers also? The evil drivers didn't for me at all. Don't know why. Other observation: powertop shows 400+ wakeups/second in gnome-shell. I assume someone familiar with gnome-shell internals would be able to spot what it is doing and what is causing it. For now I use xfce instead.
(In reply to comment #34) > The evil drivers didn't for me at all. Don't know why. Might be an UEFI issue, but reason I asked is to track down pontential dependencies for this issue especially as we are facing a very high resolution with our boxes which is something gnome might get crazy about... > For now I use xfce instead. And the high load is not there anymore? So this proves this issue is specific to gnome-shell!? Sorry for OT again: Is xfce supporting all the special keys on your MBPr?
Using cinnamon instead of gnome3 is not an workaround as there is no gnome-shell anymore but cinnamon eating up the system instead. I've the feeling it is even worse than gnome-shell...
The problem is still present after the latest upgrades Plymouth 0.8.8-5.fc18 Mar 11 10:16 initramfs-3.8.2-206.fc18.x86_64.img glxinfo|fgrep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301) GL_NV_blend_square, GL_NV_conditional_render, GL_NV_fog_distance, 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02) 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02) /etc/pam.d/system-auth -session optional pam_systemd.so
gnome-shell 3.6.3.1-1.fc18 llvmpipe ought not be the problem as a lot of CPU is used withouth any rendering on the screen.
FWIW, with the latest f18 testing updates I don't see the problem on my MacBookPro10,1.
The nouveau-drivers always got tons of errors, so i installed the 64-bit nvidia-driver from rpmfusion. Since then, gnome-shell goes up to short peaks at about 40% I will check the next days, if my system still freezes with gnome-shell having lots of load.
(In reply to comment #38) > gnome-shell 3.6.3.1-1.fc18 > > llvmpipe ought not be the problem as a lot of CPU is used withouth any > rendering on the screen. Further investigating is showing, that gnome-shell is settling down after using ctrl-alt-F2 to another screen in text mode. I have made a lot of things to avoid using GNOME3, primarily installing Xfce4 and switching display manager to lightdm It now appears, that using lightdm and a Gnome3 session no longer is causing the system to use sofware rendering by llvmpipe (checked by glxinfo|fgrep render) (it is an ATOM D510 based system with embedded graphics using the intel/i915 driver) It may not be relevant, but I also added video=LVDS-1:d as a the kernel boot parameter avoiding using an incorrectly detected screen i.e. no logon window appeared, only the background (probably caused by using a KVM switch for several PCs)
Had the problem on F18 as well. My hw is similar to Joergen's: 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02) Up to 250% cpu for gnome-shell which made the system (Dual Atom 1.8Ghz, 4Gb RAM) unusable (typing in local gnome-terminal with extreme latency) Found out that nomodeset on cmdline forces Xorg to detect vesa instead of intel. [ 20.352] (II) LoadModule: "vesa" [ 20.353] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 20.391] (II) Module vesa: vendor="X.Org Foundation" This leads to llvmpipe software rendering, which makes the desktop unusable. Removing nomodeset and adding "xdriver=intel video=LVDS-1:d " to cmdline solved the problem for me (video=LVDS-1:d to fix the same problem Joergen had.) Now Xorg detects the intel driver and everything is fine: # glxinfo| grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Intel(R) IGD
See this same behavior in F19 beta. gnome-shell settles down immediately after switching to a text console.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I'm seeing this on F18 (updated) running it on Parallels as a VM.
I'm still seeing this on the latest F18 (3.9.6-200.fc18.i686, updated). Booting without "nomodeset" in the kernel command line avoids the problem for me. Word of caution: I have removed that from GRUB_CMDLINE_LINUX in /etc/default/grub, have edited /boot/grub2/grub.cfg to remove 'nomodeset', and await the grub magic to properly migrate /etc/default/grub to /boot/grub2/grub.cfg ('mv /boot/grub2/grub.cfg /boot/grub2/grub.cfg-$(date +%Y%m%d-%H%M%S) && grub2-mkconfig -o /boot/grub2/grub.cfg' just rendered my system unbootable).
(In reply to Gunnar Hellekson from comment #43) > See this same behavior in F19 beta. gnome-shell settles down immediately > after switching to a text console. I get the exact same behavior on F19. Switching to text console does help speed up the recovery. One thing to note, my Gnome 3 spikes to 100% CPU and locks my current X session right after receiving an event (such as an IM in pidgen or popup from Chrome) that causes a notification to trigger. The lock up normally lasts one minute with gnome-shell pegging 100% CPU.
Upgraded from F17 to F19 using FedUp. Has similar behavior. With just the laptop's monitor it is OK. Attaching an external, second monitor causes gnome-shell process to use CPU at around 100% to 160% CPU (dual core machine). Seems to last indefinitely. Using 'renice 20 PID' causes gnome-shell to run at about 90% CPU (on one core). Removing external monitor causes behavior to disappear. Seems to occur in both Gnome and Gnome classic. Version 3.8.4. Did not notice this in F17. With one monitor gnome-shell uses ~20% CPU. Switch to KDM and the problem remains. (yum install kdm;systemctl enable kdm.service;systemctl disable gdm.service;) And then switch to LXDE (which was installed quite some time ago) resolves the issue. Two monitors runs as expected. Process "X" runs at about ~2% CPU, ~95% idle. 3.10.5-201.fc19.i686, integrated Intel 945GM.
I am affected by this bug in Fedora 20. It is amazing that we still have not figured this out. I am connected via VNC and look: KiB Swap: 12394492 total, 0 used, 12394492 free, 2968108 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3324 smbuser 20 0 1035252 42340 25124 R 80.1 0.2 26:00.93 /usr/libexec/gnome-initial-setup 1025 root 20 0 178292 17060 7828 R 27.9 0.1 9:17.47 /usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/auth-for-gdm-v0AvFu/da+ 3466 smbuser 20 0 478844 13340 9480 S 6.3 0.1 1:58.98 /usr/libexec/gnome-session-failed --allow-logout As you can see,gnome-initial-setup is eating 80% of a core, and Xorg is taking an addtional 30%. Completely unacceptable. Any idea?
I am now seeing this on Fedora 20. I did not have the problem on Fedora 19.
Anyone know anything?
Seems to be related: https://bugzilla.gnome.org/show_bug.cgi?id=719418
Still seeing this problem on an F17 machine: # top top - 21:45:20 up 20 days, 10:52, 5 users, load average: 6.30, 4.24, 3.65 Tasks: 274 total, 2 running, 271 sleeping, 0 stopped, 1 zombie Cpu(s): 13.5%us, 5.8%sy, 0.0%ni, 80.0%id, 0.3%wa, 0.3%hi, 0.1%si, 0.0%st Mem: 32842188k total, 32237528k used, 604660k free, 115152k buffers Swap: 67076092k total, 1051676k used, 66024416k free, 679320k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7261 gerryr 20 0 1735m 177m 16m S 475.2 0.6 12617:11 gnome-shell $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300) This machine has an Intel HD P4000 GPU so why is it using llvmpipe? gnome-shell is wrecking this machine.
Re: comment 53 - F17 is no longer supported. That said, people are still seeing gnome-shell consume inordinate amounts of memory (https://bugzilla.redhat.com/show_bug.cgi?id=977387) and/or cpu in supported releases, particularly on machines with modest resources. It's not clear if anyone upstream is considering any patches to help (if so, I haven't seen any). Workarounds include using a different desktop environment, and manually using alt+r periodically.
Same problem. Freshly installed Fedora 20 machine.
In comment 54, of course I meant alt-f2 + r (not alt + r).
I am now having this problem with Fedora 20. I didn't have it with 17, or 19 (did not try 18).
Created attachment 900260 [details] lspci Me too, on F20. Happens only when Chrome is open.
It would be really helpful to find out what functions gnome-shell is spending its time in when this happens. On a machine this problem is occurring on install the debuginfo related to gnome shell and perf with: # debuginfo-install gnome-shell -y # yum install perf -y When the problem occurs again run the following to see where gnome-shell is spending time : # perf top To limit perf to monitoring gnome-shell you could do: # perf top -p `pgrep -d "," gnome-shell`
Created attachment 900693 [details] perf screenshot Here you go, William. Another piece of info is that Chrome was also consuming ~80% CPU on plain web pages, until I disabled everything related to GPU in chrome://flags If I close Chrome, gnome-shell also stops using CPU.
Those functions look pretty generic. It might be useful to get call profiles with callstack for both gnome-shell and chrome. When the gnome-shell high load is occurring run the following for several seconds as root: perf record -g -p `pgrep -d "," gnome-shell` -o gnome-shell.data Then write the date out in human readable form: perf report -i gnome-shell.data --stdio > gnome-shell.profile Given that Chrome is also having a lot of load maybe also do something similar for it: perf record -g -p `pgrep -d "," chrome` -o chrome.data Then output the data: perf report -i chrome.data --stdio > chrome.profile However, it is possible that chrome is dynamically generating code and there is just going to be a bunch of hex addresses that are not going to be too useful. Could it be that there is a badly behaving html page that chrome is trying to render? Maybe try narrowing down which tab is the offending one and then use the javascript profiler on https://developer.chrome.com/devtools/docs/cpu-profiling to find out what is going on.
Created attachment 901031 [details] gnome-shell.profile # perf report -i gnome-shell.data --stdio > gnome-shell.profile Failed to open /tmp/perf-1497.map, continuing without symbols Failed to open [vsyscall], continuing without symbols
Chrome no longer uses CPU constantly after I disabled everything related to GPU in chrome://flags Thanks
Created attachment 901200 [details] perf profile of gnome-shell using high CPU Here is the perf profile for the gnome-shell session using high CPU (> 30% in a dual cpu system) in my case. This is associated with increased memory usage (~700 MB RES at the time of the perf record) where I usually do 'alt-f2 r' to keep the laptop from running hotter. But if I don't, memory and cpu usage continue to grow and eventually the session begins to become unresponsive. So in my case, it seems pretty clearly associated with symptoms that have the appearance of a memory leak.
Still happens to me as well after Fed20 upgrade with Chrome open. The workstation is so frozen that I rarely even get a chance to be able to do a Alt+F2 r, so I've to restart gdm and loose all my workspace :( Linux stormbringer 3.15.10-200.fc20.x86_64 #1 SMP Thu Aug 14 15:39:24 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
In my case, from 15% to 25% CPU is constantly consumed by gnome-shell. RHEL 7 on ThinkPad X230. When I switch to text terminal by Ctrl-Alt-F2, it stops. # uname -a Linux ontpx230 3.10.0-123.13.2.el7.x86_64 #1 SMP Fri Dec 12 19:51:03 EST 2014 x86_64 x86_64 x86_64 GNU/Linux # debuginfo-install gnome-shell -y # perf top -p `pgrep -d "," gnome-shell` 5.17% libclutter-1.0.so.0.1404.0 [.] clutter_actor_get_type 5.15% i965_dri.so [.] 0x0000000000011ce1 3.62% libglib-2.0.so.0.3600.3 [.] g_source_iter_next 2.57% libglib-2.0.so.0.3600.3 [.] g_hash_table_lookup 2.28% libgobject-2.0.so.0.3600.3 [.] g_type_check_instance_is_a 2.05% libglib-2.0.so.0.3600.3 [.] g_mutex_get_impl 1.34% libclutter-1.0.so.0.1404.0 [.] _clutter_actor_get_stage_internal 1.34% libpthread-2.17.so [.] pthread_mutex_lock ... # pstack $THE_PID ... Thread 1 (Thread 0x7f1ab81e0a00 (LWP 17191)): #0 0x00007f1aae55fbdd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f1aac3c9f72 in _xcb_conn_wait () from /lib64/libxcb.so.1 #2 0x00007f1aac3cb42f in wait_for_reply () from /lib64/libxcb.so.1 #3 0x00007f1aac3cb542 in xcb_wait_for_reply () from /lib64/libxcb.so.1 #4 0x00007f1ab0cc7eff in _XReply (dpy=0x17cd040, rep=0x7fffd04dab20, extra=0, discard=0) at xcb_io.c:602 #5 0x00007f1aa7d5682b in DRI2GetBuffersWithFormat () from /lib64/libGL.so.1 #6 0x00007f1aa7d5415b in dri2GetBuffersWithFormat () from /lib64/libGL.so.1 #7 0x00007f1a9c2b2f31 in intel_update_renderbuffers () from /usr/lib64/dri/i965_dri.so #8 0x00007f1a9c2b3223 in intel_prepare_render () from /usr/lib64/dri/i965_dri.so #9 0x00007f1a9c2d26bf in brw_draw_prims () from /usr/lib64/dri/i965_dri.so #10 0x00007f1a97b56cc0 in vbo_draw_arrays () from /lib64/libdricore9.2.5.so.1 #11 0x00007f1ab21afdc8 in _cogl_framebuffer_gl_draw_attributes (framebuffer=0x2f4ac10, pipeline=<optimized out>, mode=7, first_vertex=0, n_vertices=4, attributes=<optimized out>, n_attributes=2, flags=(COGL_DRAW_SKIP_JOURNAL_FLUSH | COGL_DRAW_SKIP_PIPELINE_VALIDATION | COGL_DRAW_SKIP_FRAMEBUFFER_FLUSH | COGL_DRAW_SKIP_LEGACY_STATE | COGL_DRAW_COLOR_ATTRIBUTE_IS_OPAQUE)) at driver/gl/cogl-framebuffer-gl.c:1071 #12 0x00007f1ab21fa916 in _cogl_journal_flush_modelview_and_entries (batch_start=<optimized out>, batch_len=1, data=0x7fffd04dafa0) at ./cogl-journal.c:305 #13 0x00007f1ab21fa6b4 in _cogl_journal_flush_texcoord_vbo_offsets_and_entries (batch_start=0x5264000, batch_len=1, data=0x7fffd04dafa0) at ./cogl-journal.c:556 #14 0x00007f1ab21fa539 in _cogl_journal_flush_vbo_offsets_and_entries (batch_start=0x5264000, batch_len=1, data=<optimized out>) at ./cogl-journal.c:663 #15 0x00007f1ab21fbb53 in _cogl_journal_flush (journal=0x1810c20) at ./cogl-journal.c:1375 #16 0x00007f1ab21fcb0c in _cogl_framebuffer_flush_journal (framebuffer=framebuffer@entry=0x2f4ac10) at ./cogl-framebuffer.c:595 #17 0x00007f1ab21fd623 in cogl_framebuffer_clear4f (framebuffer=0x2f4ac10, buffers=2, red=0.180392161, green=0.203921571, green@entry=0, blue=0.211764708, blue@entry=-1.38038149e+10, alpha=1, alpha@entry=4.59163468e-41) at ./cogl-framebuffer.c:339 #18 0x00007f1ab21fd988 in cogl_framebuffer_clear (framebuffer=<optimized out>, buffers=<optimized out>, color=color@entry=0x7fffd04db160) at ./cogl-framebuffer.c:440 #19 0x00007f1ab21c89c5 in cogl_clear (color=color@entry=0x7fffd04db160, buffers=<optimized out>) at ./cogl.c:87 #20 0x00007f1ab2b1fd79 in clutter_stage_paint (self=0x2f62eb0) at ./clutter-stage.c:720 #21 0x00007f1aaeb6dd27 in _g_closure_invoke_va (closure=closure@entry=0x2f65e60, return_value=return_value@entry=0x0, instance=instance@entry=0x2f62eb0, args=args@entry=0x7fffd04db390, n_params=0, param_types=0x0) at gclosure.c:840 #22 0x00007f1aaeb8658d in g_signal_emit_valist (instance=0x2f62eb0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffd04db390) at gsignal.c:3234 #23 0x00007f1aaeb8723f in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3384 #24 0x00007f1ab2ac61f9 in clutter_actor_continue_paint (self=0x2f62eb0) at ./clutter-actor.c:3892 #25 0x00007f1ab2acc5dd in clutter_actor_paint (self=self@entry=0x2f62eb0) at ./clutter-actor.c:3816 #26 0x00007f1ab2b23e7c in _clutter_stage_do_paint (stage=stage@entry=0x2f62eb0, clip=clip@entry=0x0) at ./clutter-stage.c:676 #27 0x00007f1ab2abce40 in clutter_stage_cogl_redraw (stage_window=0x1810b70) at cogl/clutter-stage-cogl.c:559 #28 0x00007f1ab2b227b3 in clutter_stage_do_redraw (stage=0x2f62eb0) at ./clutter-stage.c:1180 #29 _clutter_stage_do_update (stage=0x2f62eb0) at ./clutter-stage.c:1238 #30 0x00007f1ab2b087f8 in master_clock_update_stages (master_clock=0x2ebeb80, stages=0x5bc8290 = {...}) at ./clutter-master-clock.c:457 #31 clutter_clock_dispatch (source=source@entry=0x2eccda0, callback=<optimized out>, user_data=<optimized out>) at ./clutter-master-clock.c:589 #32 0x00007f1aae87dac6 in g_main_dispatch (context=0x17aad80) at gmain.c:3058 #33 g_main_context_dispatch (context=context@entry=0x17aad80) at gmain.c:3634 #34 0x00007f1aae87de48 in g_main_context_iterate (context=0x17aad80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3705 #35 0x00007f1aae87e25a in g_main_loop_run (loop=0x17ad9c0) at gmain.c:3899 #36 0x00007f1ab76cee78 in meta_run () at core/main.c:556 #37 0x0000000000401f20 in main (argc=1, argv=0x7fffd04dbac8) at main.c:412
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm having this problem with an Intel video card and F22. $ rpm -q gnome-shell gnome-shell-3.16.4-1.fc22.x86_64 $ glxinfo | grep render direct rendering: Yes GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil, GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp, GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, $ top -b -n 1 top - 00:08:16 up 56 min, 3 users, load average: 0,85, 0,76, 0,78 Tasks: 205 total, 2 running, 203 sleeping, 0 stopped, 0 zombie %Cpu(s): 17,0 us, 1,0 sy, 0,0 ni, 80,1 id, 1,8 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 3743772 total, 1980016 free, 726396 used, 1037360 buff/cache KiB Swap: 128516 total, 128516 free, 0 used. 2792628 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3915 massi 20 0 1559740 139312 57484 R 100,0 3,7 9:33.34 gnome-shell 1 root 20 0 191352 5692 3924 S 0,0 0,2 0:01.28 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0,0 0,0 0:00.11 ksoftirqd/0 If I switch to a text console the CPU slows down immediatly. No background extension enabled. Does anyone have this problem?