Description of problem: When playing a movie gnome-shell is pegged at 100%. Any keyboard or window movement causes the video to pause (audio continues). This is a regression from F14. xvinfo shows that XV is available (no idea if it is being used...) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Play a movie 2. Do anything 3. Actual results: Movie 'pauses', also other gnome-shell effects don't work well. Alt-Tab takes multiple seconds to appear, typing is delayed etc etc etc... Expected results: Smooth playing video, little CPU usage etc. Additional info: I have dual screens... 03:00.0 VGA compatible controller: ATI Technologies Inc RV730 PRO [Radeon HD 4650]
Using fallback mode, everything is really smooth. Unfortunately moving a window around has issues with redrawing (it leaves the previous window position etc). However the system is *MUCH* more responsive.
- What resolution was the movie at? - What program were you using to play it? - What are the top few lines of 'top' output when playing the movie? (That is, what processes are taking the CPU)
Totem & mplayer - though mplayer seems to be smoother and affects system performance less - odd since gnome-shell is close to 100% in both cases 13757 gnat 20 0 1463m 130m 27m R 98.4 1.1 77:07.00 gnome-shell 13456 root 20 0 222m 106m 10m S 2.7 0.9 7:03.20 Xorg 13930 gnat 20 0 922m 121m 29m S 1.7 1.0 1:02.93 thunderbird-bin 16259 gnat 20 0 3024m 293m 43m S 1.7 2.4 1:10.93 firefox 14067 gnat 20 0 566m 15m 9.9m S 1.0 0.1 0:08.15 gnome-terminal 2329 gnat 9 -11 577m 16m 14m S 0.7 0.1 4:58.59 pulseaudio 5824 gnat 20 0 505m 24m 9108 S 0.7 0.2 0:00.55 mplayer 5670 gnat 20 0 452m 20m 9.9m S 0.3 0.2 0:05.03 plugin-container 5841 gnat 20 0 15284 1320 904 R 0.3 0.0 0:00.15 top With both players, I've played at 1:1 and fullscreen on the secondary monitor. xrand -q Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192 DVI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1600x1200 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 60.0 DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1600x1200 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 60.0 xvinfo reports: X-Video Extension version 2.2 screen #0 Adaptor #0: "Radeon Textured Video" number of ports: 16 port base: 63 operations supported: PutImage supported visuals: depth 24, visualID 0x21 number of attributes: 7 "XV_VSYNC" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_COLORSPACE" (range 0 to 1) client settable attribute client gettable attribute (current value is 0) "XV_CRTC" (range -1 to 1) client settable attribute client gettable attribute (current value is -1) maximum XvImage size: 8192 x 8192 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) However the behaviour is the same regardless of which screen it is playing on.
One more tidbit... This happens even when not playing a movie. After maybe an hour of working (sans movie, just regular apps like FF, Thunderbird, Eclipse, gnome-terminal etc) gnome-shell stays between 50-80% CPU usage... Everything gets very very laggy. This wasn't an issue with F14 (obviously not gnome-shell) but with compiz... Gnome fallback mode is even worse, the windows don't re-draw so moving a window around leaves 'copies'... totally useless. I've had to install xfce to get work done but don't like it... I'm a motivated bug reporter so please feel free to ask for info.
Created attachment 502128 [details] Strace -s 2048 of gnome-shell
The repeated calls to sched_yield() are almost certainly GDBus: /* wait for the user code to run.. hmm.. probably use a condition variable instead */ while (!data->done) g_thread_yield ();
*** Bug 615545 has been marked as a duplicate of this bug. ***
In my case, using amarok to play mp3 only, pulseaudio uses nearly 10% cpu by itself and amarok uses a similar amount. While not so dramatic as 100% i still consider it a lot. Fedora 15 X86_64 KDE LiveCD also, with oss radeon driver. If i play a 1080p h264 movie (sound is not mp3) cpu goes max 45% load and pluseudio cpu consumption does not increase. (using mplayer while amarok is reproducing mp3). But if what i play is a non-hd resolution video also with mplayer with mp3 sound... pulseaudio cpu usage from 9.6% to 13% or more. why does pulseaudio uses more cpu time with mp3 that with other codecs if it not decoding anything (that i am aware of, at least).
I get this (gnome-shell at 100%) very occasionally. I don't play movies. I havn't yet found a pattern for what causes it (most recently it started some time overnight) and I'm afraid I currently don't have time to research it. Most recent case (just now) logging out did not resolve it -- gnome-shell was still at 100% after logging back in. Kernel 2.6.40.3-0.fc15.x86_64
CPU usage increases dramatically to 99% while switch between Overview and Window. Configuration details: 1.CPU:Intel(R) Atom(TM) CPU N570 @1.66GHz 2.HDD:250G(Sector size:512B) 3.RAM:1G Steps to reproduce the bug: 1.Let system idle to make sure CPU is on normal status(0.3%); 2.Hover(using Mouse) on Activities,switch between Overview and Window,do this about 5 times/5 seconds,and CPU usage increases to 90%； 3.Wait for 5 seconds,then the CPU down to normal status.
Update: Gnome-shell 3.1.4
I'm seeing this on a new installation of Fedora 16, gnome-shell 3.2.0. Over the course of several hours, even with the computer idle, the gnome-shell process grows and consumes more and more CPU, until it's pegged in the 90% range.
I am using fedora 16 with gnome-shell version 3.2.1-2.fc16. And this problem exists for me also. It is really not allowing any thing to work.
I see this on gnome-shell-3.4.0-1.fc17 using mplayer. strace of gnome-shell shows ~3500 sched_yield() calls per second. mplayer was using XV surface on nouveau driver ("Nouveau GeForce 8/9 Textured Video").
I see at least a similar, if not the same issue on Fedora 16: strace shows sched_yield like crazy and the GNOME Shell hogs the CPU and cannot be used at all. (gdb) t a a bESC[Kt full Thread 7 (Thread 0x7f76e652f700 (LWP 1875)): #0 0x00000039f20e85c3 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 resultvar = <optimized out> oldtype = 0 result = <optimized out> #1 0x00000039f4045448 in g_main_context_poll (n_fds=1, fds=0x7f76dc001170, priority=<optimized out>, timeout=-1, context=0x23b4c30) at gmain.c:3402 poll_func = 0x39f4053860 <g_poll> #2 g_main_context_iterate (context=0x23b4c30, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3084 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = <optimized out> fds = 0x7f76dc001170 __PRETTY_FUNCTION__ = "g_main_context_iterate" #3 0x00000039f4045c85 in g_main_loop_run (loop=0x7f76dc001150) at gmain.c:3297 self = 0x23b1790 __PRETTY_FUNCTION__ = "g_main_loop_run" #4 0x00007f76e65349fb in dconf_context_thread (data=0x23b4c30) at dconfcontext.c:11 context = 0x23b4c30 loop = <optimized out> __PRETTY_FUNCTION__ = "dconf_context_thread" Thread 1 (Thread 0x7f76ef55e9c0 (LWP 1859)): #0 0x00000039f20d9bd7 in sched_yield () at ../sysdeps/unix/syscall-template.S:8 2 No locals. #1 0x00007f76e7ebee26 in r600_fence_finish (pscreen=<optimized out>, fence=0x26 fe9c0, timeout=18446744073709551615) at r600_pipe.c:625 rfence = 0x26fe9c0 ctx = 0x22b1d60 start_time = 0 spins = 2655484928 #2 0x00007f76e7f9426d in st_finish (st=0x2348930) at state_tracker/st_cb_flush.c:106 fence = 0x26fe9c0 #3 0x00007f76e7f942a0 in st_glFinish (ctx=<optimized out>) at state_tracker/st_cb_flush.c:141 st = 0x2348930 #4 0x0000003a1365494c in _cogl_winsys_onscreen_swap_region (onscreen=<optimized out>, user_rectangles=<optimized out>, n_rectangles=1) at winsys/cogl-winsys-glx.c:1205 framebuffer = <optimized out> context = 0x23513a0 xlib_renderer = 0x21111c0 glx_renderer = 0x21111c0 xlib_onscreen = 0x2003700 glx_onscreen = 0x2003700 drawable = 16777229 end_frame_vsync_counter = 0 have_counter = 1 can_wait = 1 blit_sub_buffer_is_synchronized = 1 framebuffer_height = <optimized out> rectangles = 0x7fff44cd1fb0 i = <optimized out> #5 0x0000003a140316a0 in clutter_stage_cogl_redraw (stage_window=0x23539b0) at cogl/clutter-stage-cogl.c:534 clip = 0x2353a20 copy_area = {33, 0, 1217, 1017} stage_cogl = 0x23539b0 [ClutterStageCogl] wrapper = 0x23c2050 [ClutterStage] backend = <optimized out> backend_cogl = <optimized out> may_use_clipped_redraw = <optimized out> use_clipped_redraw = <optimized out> stage_x11 = 0x23539b0 [ClutterStageCogl] #6 0x0000003a140934ba in clutter_stage_do_redraw (stage=0x23c2050 [ClutterStage]) at ./clutter-stage.c:1023 backend = 0x1fdf060 [ClutterBackendCogl] actor = 0x23c2050 [ClutterStage] priv = 0x23c2400 #7 _clutter_stage_do_update (stage=0x23c2050 [ClutterStage]) at ./clutter-stage.c:1079 priv = 0x23c2400 #8 0x0000003a1407ac90 in clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./clutter-master-clock.c:384 clock_source = <optimized out> master_clock = 0x210c5c0 [ClutterMasterClock] stage_manager = <optimized out> stages_updated = <optimized out> I have more of that stacktrace in a separate file on bug 837809. (gdb) call gjs_dumpstack () (gdb) quit $ lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV730 PRO [Radeon HD 4650] $
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping