On Fri, 15 Sep 2017 05:05:07 -0700 Marc MERLIN <marc_...@merlins.org> said:

> My e21 has been stuck in a 98% CPU loop for a few days, not sure why:
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0u\27\4\0,J\10\0\va\365\0
> \0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4\0\0\0", 4)     = 4
> [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31447] futex(0x7f9da392b3e0, FUTEX_WAKE_PRIVATE, 1) = 1
> [pid 31447] ioctl(28, 0xc018643a <unfinished ...>
> [pid 31446] <... select resumed> )      = 1 (in [24])
> [pid 31447] <... ioctl resumed> , 0x7f9d9319fa70) = 0
> [pid 31446] read(24,  <unfinished ...>
> [pid 31447] select(29, [28], [], [], {0, 100000} <unfinished ...>
> [pid 31446] <... read resumed> "\0", 1) = 1
> [pid 31446] select(25, [24], [], [], NULL <unfinished ...>
> [pid 31447] <... select resumed> )      = 1 (in [28], left {0, 83798})
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0u\27\4\0G\213\10\0\fa\365
> \0\0\0\0\0", 1024) = 32 [pid 31447] futex(0x555719fa90f8,
> FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0 [pid
> 31447] ioctl(28, 0xc018643a, 0x7f9d9319fa70) = 0 [pid 31447] select(29, [28],
> [], [], {0, 100000}) = 1 (in [28], left {0, 95170}) [pid 31447] read(28, "\1\0
> \0\0 \0\0\0\0\0\0\0\0\0\0\0u\27\4\0`\314\10\0\ra\365\0\0\0\0\0", 1024) = 32
> [pid 31447] write(6, "\4\0\0\0", 4)     = 4 [pid 31447] write(6, "*\0\0\0",
> 4)      = 4 [pid 31447] futex(0x7f9da392b3e0, FUTEX_WAKE_PRIVATE, 1) = 1
> [pid 31447] futex(0x555719fa90f8, FUTEX_WAIT_BITSET_PRIVATE|
> FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff <unfinished ...> [pid 31446] <...
> select resumed> )      = 1 (in [24])
> 
> 
> Just looking at read/write:
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\277\27\4\0\362l\1\0Hr
> \365\0\0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4\0\0\0", 4)     = 4
> [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31446] read(24, "\0", 1)           = 1
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\277\27\4\0'\357\1\0Jr
> \365\0\0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4\0\0\0", 4)     = 4
> [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31446] read(24,  <unfinished ...>
> [pid 31446] <... read resumed> "\0", 1) = 1
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\277\27\4\0A0\2\0Kr\365\0
> \0\0\0\0", 1024) = 32 [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0
> \277\27\4\0^q\2\0Lr\365\0\0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4\0\0
> \0", 4)     = 4 [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31446] read(24, "\0", 1)           = 1
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\277\27\4\0u\262\2\0Mr
> \365\0\0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4\0\0\0", 4)     = 4
> [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31446] read(24,  <unfinished ...>
> [pid 31446] <... read resumed> "\0", 1) = 1
> [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\277\27\4\0\221\363\2\0Nr
> \365\0\0\0\0\0", 1024) = 32 [pid 31447] read(28, "\1\0\0\0 \0\0\0\0\0\0\0\0\0
> \0\0\277\27\4\0\2544\3\0Or\365\0\0\0\0\0", 1024) = 32 [pid 31447] write(6, "\4
> \0\0\0", 4)     = 4 [pid 31447] write(6, "*\0\0\0", 4)      = 4
> [pid 31446] read(24, "\0", 1)           = 1
> 
> 
> lsof says:
> enlighten 31441 merlin    6w  FIFO               0,12      0t0  3871696 pipe
> enlighten 31441 merlin   24r  FIFO               0,12      0t0  3871715 pipe
> enlighten 31441 merlin   28u   CHR              226,0      0t0
> 659 /dev/dri/card0
> 
> Any ideas what this could be?
> This is totally destroying my battery life.

that smells like the animator. intel graphics? for intel we open the dri device
and ask the device driver to send us vsync/vblank interrupts for animation.
this is what actually keeps our framerate perfectly synced with screen refresh
for smoothness. if this is spinning in a tight loop reading from that device ...
then something seems wrong with the device driver. it should only be producing
events every "frame refresh" and even then we only turn this on when we need it
(when we need to animate or get a frame tick). if no frame tick is on we don't
request a schedule of the vsync event. if we're getting them from the device
again and again even if we haven't asked... see above. that's what it smells
like. did this start recently after a kernel upgrade or change? perhaps a
libdrm change (we actually just find libdrm and dlopen/dlsym that and use it).
this code was written many years ago (3? 4? 5? 6? i forgot...) and has worked
solidly since then...

maybe strace with timestamps to double-check... as you should find those reads
from fd 28 about 1 frame (1/60th or so of a second depending on refresh) apart.
note if you have 2 screens you may get an event per screen as well - so more
often and maybe at different times.

> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
>                                       .... what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/                         | PGP
> 1024R/763BE901
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Reply via email to