PDA

View Full Version : Ubuntu boxee cpu pegged @ 100%



johninsj
November 11th, 2008, 09:21 AM
So, I don't know what happened, or why, but my ubuntu 8.04 installed boxee (dual core, 4gb ram, nvidia card, no resource issues) has now started pegging cpu at 100% immediately when I start it. Doesn't even wait for me to log in, just BAM 100% on one core. In fact, it's nearly impossible to log in since the GUI is so slow.

I did manage to log in yesterday, and let it run for a couple hours (maybe it was indexing?) but it never changed behavior - me leaving it alone, it pegging a core at 100%. Made the room a little warmer, so it wasn't a total waste :p

Before it was doing this the speed was great on this box.

Anything I can do to give you better feedback, let me know.

marcel
November 11th, 2008, 09:22 AM
can you send me debug logs (http://forum.boxee.tv/showthread.php?t=377)

johninsj
November 11th, 2008, 09:38 AM
This may be a double post... don't know where first post went?

johninsj
November 11th, 2008, 09:44 AM
Doing a longer run (that log was just fire up and exit, was pegged at 100% the whole time)

I'll let this one run a bit - I am tail -f'ing the log and can see it SLOWLY making 1 song resolve request a second or so...

CPU is still at 103% according to the debug info at the top of the window.

johninsj
November 11th, 2008, 10:09 AM
longer log was too long :(

162kb zipped. However, after scanning, it was still pegged at 100% so that's not it.

agentlame
November 11th, 2008, 10:57 AM
do you have compiz running?
system > preferences > appearance > visual effects > none

here is a list of other issues it might be:
http://forum.boxee.tv/showthread.php?t=345

johninsj
November 11th, 2008, 03:41 PM
do you have compiz running?
system > preferences > appearance > visual effects > none

here is a list of other issues it might be:


Yes I have compiz, no it did not change from when the system did and did not peg the cpu at 100%, direct rendering is (still) correct as well, running latest nvidia driver, etc.

The "no compiz" requirement isn't really a viable answer long term for those of us who use machines for more then just running boxee, but that's another issue all together.

agentlame
November 11th, 2008, 04:58 PM
The "no compiz" requirement isn't really a viable answer long term for those of us who use machines for more then just running boxee, but that's another issue all together.

until compiz is fixed, it is the only option.

i use my machine for more than just boxee.

johninsj
November 11th, 2008, 07:31 PM
So you're saying 100% for sure, that this is the 100% cpu bug - only triggered by boxee, just to show a black screen with two text boxes on it (the login screen is pegged at 100%)

Sounds like blaming compiz for that is stretching things a bit, but what do I know.

agentlame
November 11th, 2008, 08:29 PM
sorry, i should have been more clear. that's not what i meant. i was simply saying the fixing boxee to work without disabling compiz is not very feasible, at the moment.

long:
the problem is that boxee is not 'just displaying two text boxes' the problem is that boxee/xbmc are written using sdl. sdl is a gross-platform toolkit aimed at creating video games. so running a 3d rendered application within a 3d rendered desktop does not pan-out well. (ie: fire-up doom3 three while running compiz, it will kill your cpu long before the game even finishes loading.)

short:
direct rendering can not be toggled between application using compiz.
--------------------------------------------------------------------------

but even all that said, i'm not even saying that this is the cause of you bug... i'm just trying to better explain boxee -vs- compiz, and why it's important that compiz be disabled to help narrow down what IS causing the bug. :)

johninsj
November 11th, 2008, 08:33 PM
Yep I hear you, except in this case my OS setup did not change, but something in boxee changed over the past few revs that rendered it borked. Maybe a setting is corrupted. Maybe sunspots. Most likely not compiz.

agentlame
November 11th, 2008, 08:44 PM
have you tried backing-up, then deleting you boxee config directory?



mv ~/.boxee ~/boxee-bkp
rm -rf ~/.boxee

richardrebel
May 17th, 2009, 03:44 PM
I am having this issue on 8.10, and on 9.04. I compiled 64 bit versions out of svn.

Also, this is occurs with XBMC, and it is the culprit. Doing an strace to see what boxee or xbmc are doing gets this:


[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64198, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64200, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64202, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64204, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64206, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64208, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64210, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64212, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64214, ru_nivcsw=19063}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34110, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64216, ru_nivcsw=19063}) = 0
[ 7f56a5677742] select(12, [11], [11], NULL, NULL) = 1 (out [11])
[ 7f56a567722c] writev(11, [{"\2\0\4\0\25\0\200\3\0@\0\0\23\0\200\3+\0\1\0"..., 20}, {NULL, 0}, {""..., 0}], 3) = 20
[ 7f56a5677742] select(12, [11], [], NULL, NULL) = 1 (in [11])
[ 7f56a5670f4b] read(11, "\1\1*\7\0\0\0\0\3\0\200\3\0\0\0\0000\372\240\1\0\0 \0\0\0\0\0\0\0\0\0\0"..., 4096) = 32
[ 7f56a5670f4b] read(11, 0x1c85e44, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[ 7f56a5670f4b] read(11, 0x1c85e44, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[ 7f56a5677742] select(12, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
[ 7f56a5670f4b] read(15, 0x7f569db5c000, 4096) = -1 EAGAIN (Resource temporarily unavailable)

[SNIP]

[ 7f56a60f3c89] getpid() = 10468
[ 7f56a60f3c89] getpid() = 10468
[ 7f56a60f3c89] getpid() = 10468
[ 7f56a5670b5b] open("/proc/meminfo", O_RDONLY) = 22
[ 7f56a5670284] fstat(22, {st_dev=makedev(0, 3), st_ino=4026531984, st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=0, st_size=0, st_atime=2009/05/17-16:28:24, st_mtime=2009/05/17-16:28:24, st_ctime=2009/05/17-16:28:24}) = 0
[ 7f56a567b8da] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f56ab95d000
[ 7f56a5670f4b] read(22, "MemTotal: 978628 kB\nMemFr"..., 1024) = 1024
[ 7f56a5670f4b] read(22, "12 kB\nDirectMap2M: 57344 kB"..., 1024) = 34
[ 7f56a5670f4b] read(22, ""..., 1024) = 0
[ 7f56a5670f4b] read(22, ""..., 1024) = 0
[ 7f56a5670ea0] close(22) = 0
[ 7f56a567b907] munmap(0x7f56ab95d000, 4096) = 0
[ 7f56a60f3c89] getpid() = 10468
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34111, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64288, ru_nivcsw=19064}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34111, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64290, ru_nivcsw=19064}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34111, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64292, ru_nivcsw=19064}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34111, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64294, ru_nivcsw=19064}) = 0
[ 7f56a5676687] getrusage(RUSAGE_SELF, {ru_utime={11, 40000}, ru_stime={28, 700000}, ru_maxrss=0, ru_ixrss=0, ru_idrss=0, ru_isrss=0, ru_minflt=34111, ru_majflt=66, ru_nswap=0, ru_inblock=11296, ru_oublock=3672, ru_msgsnd=0, ru_msgrcv=0, ru_nsignals=0, ru_nvcsw=64296, ru_nivcsw=19064}) = 0
[ 7f56a60f3c89] getpid() = 10468
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0
[ 7f56a5664c57] sched_yield() = 0

And the sched_yield() calls happen thousands of times per second. Then a repeat of the calls above ad nauseum eating up a whole core. Boxee is heavier than xbmc and is just unusable. XBMC is usable at least. Boxee on OSX works OOB, but my HTPC is a 4TB Linux system which serves several other purposes (runs my dvd ripping robot etc).

BTW, I suspect something in the kernel or libc changed and something they expect will block/wait no longer does and spins on sched_yield().

The XBMC developers are rather snappy and childish so aside from try and convince them to look into this on the forums, don't expect much. The boxee and xbmc devs don't think 64 bit targets are important. It is, in the HTPC market and it will have to be dealt with eventually, but I am tired of trying to convince their teams. I am not going to waste a weeks time with gdb and debugging their code for them either because they are just that obnoxious.

*sigh*

-rr

motd2k
July 22nd, 2009, 10:27 AM
This snappy, childish, XBMC dev is looking into it. On a positive note, thanks for a good bug report.

motd2k
July 22nd, 2009, 10:50 AM
Could anyone with this problem try...


pulseaudio --kill before launching XBMC/Boxee and report back if it made a difference?



motd