netbook-launcher generates high CPU Load - after click on Home icon

[Christian Ide]

Binary package hint: netbook-launcher

netbook-launcher uses much CPU time in foreground and in background. Starting via terminal I get the repeated lines:

Clutter-CRITICAL **: clutter_timeline_do_tick: assertion `CLUTTER_IS_TIMELINE (timeline)' failed

My Hardware: Acer Aspire One 110 with Intel Atom and Intel 945 graphic.

ProblemType: Bug
Architecture: i386
Date: Mon Sep 7 17:24:59 2009
DistroRelease: Ubuntu 9.10
Package: netbook-launcher 2.1.5-0ubuntu2
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.29-generic
SourcePackage: netbook-launcher
Tags: ubuntu-unr
Uname: Linux 2.6.31-9-generic i686

[Jason Smith (jassmith)]

Do those errors only occur when you mouse over the up/down arrows on the menu bar on the left?

[Jonas Bonn (jonas.bonn)]

No... the high CPU load starts in conjunction with launching an
application (I think)... I haven't had much luck in isolating the
except start of activity.
On an Asus Aspire, the CPU load of netbook-launcher stays at around 20%.

[Jonas Bonn (jonas.bonn)]

No... the CPU activity begins in conjunction with launching an application (I think)... it's difficult to see exactly when the CPU activity begins. It may be that one has to return to the netbook launcher (desktop) again before it begins.
On an ACER Aspire, CPU acitvity lies constantly at around 20% when the high CPU activity begins.

[Jason Smith (jassmith)]

It is hard to say for sure what is going on with you. Clearly netbook launcher is doing some kind of work in the background, and the timer ticks point to a known issue. I have added some bounds checking code into trunk to prevent the timers from going on forever in the background, however I wont know if this is your problem until you test it. You will still get those CLUTTER_IS_TIMELINE errors, but not to the same degree as before.

[Paul Larson (pwlars)]

Christian, does it lock up on you or anything when it does this? or does it continue to work (though consuming too much cpu)?

[Luis Aranguren (pizzaman)]

I can reproduce this bug every single time I run netbook-launcher. After a "while", and clicking on the go-home-applet a few times netbook-launcher rises to constant ~30% CPU usage, computer and application remains completely responsive and not noticeable effects occur (except warm lap).

[Jonathan Reeve (jon-reeve)]

I've been getting high CPU usage with netbook-launcher too, and I'm on an MSI Wind (Intel Atom CPU), using 2.6.31-10-generic on Karmic with the latest updates as of today.

[Jason Smith (jassmith)]

Can you please confirm that the current gnometris (in karmic) when paused has 0% CPU usage for you guys? May sound like an odd request, but it is also a clutter app and I am curious if maybe clutter is causing the issue.

[Christian Ide (cide)]

I'm not sure if the problem still exists. On my system netbooklauncher doesn't seem to use high cpu load any longer when idle. I can't reproduce the behaviour any more.

[moli (f-launchpad-moli-hu)]

i am using msi wind u100 + ubuntu 9.04 and this bug appeared after i DIS(!)connected a connected external monitor from the dsub of the laptop. internal display is 1024x600, external was 1024x768 on a 2048x~1158 monitor. while connected netbook-launcher was fine. after disconnecting the bug appeared. it starts when i mouseover any icon on the desktop or clicking on go home applet to reveal the desktop, the graphical "animation" is extremely slow (about 8 seconds for recoloring appname to orange and enlarging icon) and cpu goes to 50% (hyperthread atom). when i alttab to an application and hide the desktop cpu load goes down in about 4 seconds.

i have this in syslog every 2 seconds _*WHEN*_ THE cpu is under LOAD:
kernel: [ 2153.331349] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22

[moli (f-launchpad-moli-hu)]

sorry, i forgot to tell the solution :/
http://www.linuxforums.org/forum/linux-desktop-x-windows/147750-netbook-launcher-using-100-cpu.html

[Jason Smith (jassmith)]

Ok so its pretty clear this is a video driver/xorg issue. We cant fix this performance issue within the netbook launcher, however I do feel it falls within the scope of the Ubuntu as a whole. I am going to retarget this bug toward Xorg.

[watkin5 (robert-watkin5)]

I've seen this same issue on my eee pc 1000.
Jason, gnometris shows as 40 - 70% cpu in top.
moli, dpkg-reconfigure -phigh xserver-xorg and a reboot seems to have fix it.

[FloB (flolp)]

Not entirely sure I've still got the same problem here, but netbook-launcher is crippled again
and it sure looks identical.
I'm running on an MSI Wind U100 with Karmic netbook remix.

While in beta, I could resolve the issue by creating an xorg.conf without the "Virtual"-option
(dpkg-reconfigure xserver-xorg didn't work for me).

Now (since my last update I think...) netbook-launcher is again unusable slow, taking about 10
seconds to appear after invoked over the panel icon, and about 5 seconds to highlight an icon.

The CPU load of netbook-launcher rises to about 30% maximum, but mostly stays low, as opposed
to 100% earlier.
However, I get some
     Clutter-CRITICAL **: clutter_timeline_do_tick: assertion `CLUTTER_IS_TIMELINE (timeline)' failed

gnometris has got the same laggy behaviour, but stays at <10% CPU. It gives me the error:
     ClutterGLX-CRITICAL **: Unable to make the stage window 0x540003b the current GLX drawable

I attached the netbook-launcher output of my test session.

[dgknox (dgknox)]

I'm seeing 60-90% CPU utilization by netbook launcher while running Firefox.
as suggested above and here
http://www.linuxforums.org/forum/linux-desktop-x-windows/147750-netbook-launcher-using-100-cpu.html
I tried
Run "dpkg-reconfigure -phigh xserver-xorg" as described in the xorg.conf file's comments.

didn't help

What is the current status? can I learn more from xorg somewhere?

[theking2 (johannes-kingma)]

netbook-launcher is useing 74% CPU persistently on ubuntu lucid and eeebox N206 after a fresh install. having firefox running ssems nothing to do with it. Although after a fresh restart the problem is no there.

[Rolf Leggewie (r0lf)]

I've seen high load in netbook-launcher myself. Asus 1001P.

[Rolf Leggewie (r0lf)]

moving over to the xserver-xorg-video-intel package for further triage.

[James Dick (jamesmdick)]

this bug has resurfaced after some updates recently. i believe they were Xorg related.

now, intermittently after I suspend and resume my netbook, I get this:

top - 12:54:05 up 2 days, 15:00, 4 users, load average: 3.24, 1.98, 0.99
Tasks: 206 total, 2 running, 204 sleeping, 0 stopped, 0 zombie
Cpu(s): 54.0%us, 2.8%sy, 1.2%ni, 42.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2053216k total, 1933164k used, 120052k free, 68920k buffers
Swap: 1052216k total, 378128k used, 674088k free, 314340k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5125 james 20 0 175m 102m 16m R 99 5.1 5:17.15 netbook-launche <--------- too high!
 2519 james 20 0 259m 37m 9956 S 7 1.9 39:41.80 chrome

it's frustrating and annoying to have to kill off the launcher 2 or 3 times a day.

this is 10.04 and is supposed to be stable. when will this be addressed?

thanks,
james.

[Chris Wilson (ickle)]

The suggestion here is a GPU hang at some point, and just the general foolish of trying to use OpenGL on i915.

[Rolf Leggewie (r0lf)]

Chris, thank you for your comment. I'm sure that others like me will not understand what to do now based on your comment #21. can you please explain?

[Chris Wilson (ickle)]

The first point is easily solved by attaching an Xorg.0.log, dmesg from after the slow down. That will confirm whether or not is an application or driver bug. Following that, profiling the system when the launcher show abnormally high loads will tell us where to look for the bug and probable fix - however, since this i915 which is not very capable hardware the the OpenGL driver is abysmal it is likely to be using software rasterisation instead of hardware acceleration. (With a semi-decent driver this would not even be an issue, but alas, you choose to use OpenGL.)

[Rolf Leggewie (r0lf)]

Furthermore, you set the status to incomplete in #21 without asking any question. What data do you need? I will reset to confirmed for now since there is no additional information that the users can provide.

[Rolf Leggewie (r0lf)]

Thank you, Chris, for the lightning-fast response. So fast indeed, that our comments crossed.

Resetting to incomplete so that people affected by this bug can provide the information (me included, but unfortunately the affected machine's display broke and is thousands of miles away at the moment, maybe others can pitch in).

What is the alternative to OpenGL? I do not understand enough about this to make a conscious choice here, really. Others may be in a similar situation.