#cubox irc log of Wed 01 Oct 2014

IRC log of #cubox of Wed 01 Oct 2014. All times are in CEST < Back to index

10:12 curlymo jnettlet, are you guys aware of this error in kernel 3.14.14? http://pastebin.com/7fZMQRhz

10:16 jnettlet curlymo, that isn't an error. It means the binary drivers requested the GPU state be dumped due to an error.

10:16 jnettlet that is something the binary userspace is doing so nothing for us to fix

10:16 curlymo so it's an xbmc issue?

10:17 jnettlet could be, or could be an issue with the binaries drivers

10:17 jnettlet binary driveres

10:17 jnettlet forget it, I can't type today.

10:17 curlymo can you elaborate? What are these binary drivers?

10:19 jnettlet ???

10:19 jnettlet they are the proprietary graphics drivers from vivante that freescale provides

10:20 curlymo aha

10:20 curlymo but it doesn't occur in the 3.10.y branch...

10:38 curlymo in regard to my last question? Why doesn't this error occur in kernel 3.10.y?

10:42 jnettlet probably a kernel option is enabled that wasn't before so the gpu dumps weren't printed out

10:55 curlymo could be, but the difference is that when using 3.10.y XBMC never crashes while on 3.14.14 it does.

11:00 jnettlet curlymo, you would need to provide xbmc debug logs of a the crash to have any idea of what is really going on. That message is not causing the crash.

11:01 jnettlet in general 3.14.14 is working a lot more efficiently, you will generally see atleast a 20% increase in fps going from 3.10 to 3.14

11:01 jnettlet the performance optimizations could very well be exposing a race in XBMC

11:02 curlymo the problem is that the system just totally hangs and often doesn't even boot. So getting the logs is not possible.

11:02 jnettlet which distro is this?

11:03 jnettlet I have never seen this behaviour with 3.14.14

11:03 curlymo xbian

11:03 curlymo currently testing it

11:03 jnettlet neither geexbox or openelec have this problem, so it is most likely something specific to xbian

11:04 curlymo [2014-09-11 14:43:47] we are talking about 3.14 already right?

11:04 curlymo [2014-09-11 14:43:53] no

11:04 curlymo [2014-09-11 14:44:16] why not

11:04 curlymo [2014-09-11 14:45:08] I can't get 48h+ uptime

11:04 curlymo [2014-09-11 14:45:23] what happens

11:04 curlymo [2014-09-11 14:45:29] after ~12h-24h played videos

11:04 curlymo [2014-09-11 14:45:50] are getting distorsions - like when you gave poor signal on DVBT

11:04 curlymo [2014-09-11 14:46:00] or like if you are missing part of file

11:04 curlymo this is what mk01 stated about the issue

11:06 jnettlet my video test machine played back 1080p 80Mbps at 24fps for an entire week straight using geexbox

11:08 jnettlet curlymo, xbian is also carrying additional kernel patches on top of the kernel

11:08 curlymo yes

11:08 jnettlet I can't support that

11:08 jnettlet it is impossible

11:08 jnettlet test with a generic 3.14.14 kernel and get back to me

11:09 curlymo we ofc need btrfs lz4

11:10 jnettlet then it is up to your kernel developers to test and fix these things.

11:10 jnettlet I am looking at the repo and there 10 gpu patches on top of my kernel

11:10 jnettlet how can a sane person make that many changes and then come and complain to me that my kernel is causing problems?

11:11 curlymo i was not saying that

11:11 jnettlet if xbian wants to do their own thing that is great, but then they need to provide support for it

11:12 jnettlet I don't have the bandwidth to cleanup their messes

11:13 curlymo i just asked it you were aware of the issue that could occur with 3.14.14. An answer, "no please test with with a clean kernel" would have been sufficient.

11:15 curlymo but i will get back to you when i have test results from a clean compilation

11:54 R0nd I'm getting this error when compiling latest xbmc, any idea what went wrong?

11:54 R0nd LinuxRendererGLES.cpp:83:32: error: 'void* (* eglCreateSyncKHR)(EGLDisplay, EGLenum, const EGLint*)' redeclared as different kind of symbol

11:54 R0nd In file included from /usr/local/include/EGL/egl.h:327:0,

11:54 R0nd from /media/esata/xbmc/xbmc/windowing/egl/WinSystemEGL.h:28,

11:54 R0nd from /media/esata/xbmc/xbmc/windowing/WindowingFactory.h:39,

11:54 R0nd from LinuxRendererGLES.cpp:45:

11:55 R0nd usr/local/include/EGL/eglext.h:144:31: error: previous declaration of 'void* eglCreateSyncKHR(EGLDisplay, EGLenum, const EGLint*)'

11:56 R0nd there are duplicate declarations of several functions in eglext.h and xbmc sources, maybe my xbmc configuration is wrong?

12:59 Humpelstilzchen R0nd: what configure arguments did you use?

12:59 R0nd --disable-vdpau --disable-vaapi --enable-gles --disable-pulse --disable-projectm --enable-codec=imxvpu --disable-openmax --disable-x11 --disable-xrandr --disable-gl --disable-sdl

13:03 Humpelstilzchen thats indeed a new change

13:04 R0nd I tried commenting out the duplicates in eglext.h, but xbmc crashes that way

13:06 Humpelstilzchen my xbmc doesn't have these yet

13:08 R0nd what commit are you on?

13:08 Humpelstilzchen 4cbf9e0

13:13 Humpelstilzchen this might be a bug, depends on the reason why the define EGL_KHR_reusable_sync is set

13:50 curlymo jnettlet, i did a clean compile of your kernel but: [ 62.177371] [galcore]: GPU[0] hang, automatic recovery.

13:50 curlymo [ 82.177488] [galcore]: GPU[0] hang, automatic recovery.

13:50 curlymo [ 102.177603] [galcore]: GPU[0] hang, automatic recovery.

13:50 curlymo [ 122.177743] [galcore]: GPU[0] hang, automatic recovery.

13:51 curlymo [ 142.177839] [galcore]: GPU[0] hang, automatic recovery.

13:55 R0nd huh, I've checked out the same commit but the error didn't go away

14:30 Humpelstilzchen R0nd: done make clean?

14:31 R0nd yep

14:33 R0nd are you using the same configuration options?

14:34 Humpelstilzchen I think so, they look familiar

14:35 Humpelstilzchen might a broken header

14:36 Humpelstilzchen do you have any duplicate headers? One in /usr/local/include that is also in /usr/include

14:38 R0nd doesn't look like it

14:38 Humpelstilzchen where did you put your downloaded imx-libs headers?

14:54 R0nd tbh I don't remember

14:55 R0nd what's the filename I should look for?

15:09 Humpelstilzchen R0nd: something like imx-vpu-3.10.17 and gpu-viv-bin-mx6q-3.10.17

15:10 Humpelstilzchen one of them or both did come with headers

15:12 R0nd imx-vpu headers are in /usr/include

15:12 Humpelstilzchen and the /usr/local headers?

15:14 R0nd there's EGL, GLES etc in /usr/local/include

15:36 curlymo jnettlet, any idea what could cause the gpu hangs?

15:38 jnettlet curlymo, considering nobody is seeing them but xbian, my guess is something they have done to xbmc

15:39 wrexem Did you guys see Hummingboard up on Hackaday?

15:39 wrexem http://hackaday.com/2014/09/22/freescale-and-texas-instruments-goodies-and-world-maker-faire/

15:41 jnettlet very cool

10:12	curlymo	jnettlet, are you guys aware of this error in kernel 3.14.14? http://pastebin.com/7fZMQRhz
10:16	jnettlet	curlymo, that isn't an error. It means the binary drivers requested the GPU state be dumped due to an error.
10:16	jnettlet	that is something the binary userspace is doing so nothing for us to fix
10:16	curlymo	so it's an xbmc issue?
10:17	jnettlet	could be, or could be an issue with the binaries drivers
10:17	jnettlet	binary driveres
10:17	jnettlet	forget it, I can't type today.
10:17	curlymo	can you elaborate? What are these binary drivers?
10:19	jnettlet	???
10:19	jnettlet	they are the proprietary graphics drivers from vivante that freescale provides
10:20	curlymo	aha
10:20	curlymo	but it doesn't occur in the 3.10.y branch...
10:38	curlymo	in regard to my last question? Why doesn't this error occur in kernel 3.10.y?
10:42	jnettlet	probably a kernel option is enabled that wasn't before so the gpu dumps weren't printed out
10:55	curlymo	could be, but the difference is that when using 3.10.y XBMC never crashes while on 3.14.14 it does.
11:00	jnettlet	curlymo, you would need to provide xbmc debug logs of a the crash to have any idea of what is really going on. That message is not causing the crash.
11:01	jnettlet	in general 3.14.14 is working a lot more efficiently, you will generally see atleast a 20% increase in fps going from 3.10 to 3.14
11:01	jnettlet	the performance optimizations could very well be exposing a race in XBMC
11:02	curlymo	the problem is that the system just totally hangs and often doesn't even boot. So getting the logs is not possible.
11:02	jnettlet	which distro is this?
11:03	jnettlet	I have never seen this behaviour with 3.14.14
11:03	curlymo	xbian
11:03	curlymo	currently testing it
11:03	jnettlet	neither geexbox or openelec have this problem, so it is most likely something specific to xbian
11:04	curlymo	[2014-09-11 14:43:47] we are talking about 3.14 already right?
11:04	curlymo	[2014-09-11 14:43:53] no
11:04	curlymo	[2014-09-11 14:44:16] why not
11:04	curlymo	[2014-09-11 14:45:08] I can't get 48h+ uptime
11:04	curlymo	[2014-09-11 14:45:23] what happens
11:04	curlymo	[2014-09-11 14:45:29] after ~12h-24h played videos
11:04	curlymo	[2014-09-11 14:45:50] are getting distorsions - like when you gave poor signal on DVBT
11:04	curlymo	[2014-09-11 14:46:00] or like if you are missing part of file
11:04	curlymo	this is what mk01 stated about the issue
11:06	jnettlet	my video test machine played back 1080p 80Mbps at 24fps for an entire week straight using geexbox
11:08	jnettlet	curlymo, xbian is also carrying additional kernel patches on top of the kernel
11:08	curlymo	yes
11:08	jnettlet	I can't support that
11:08	jnettlet	it is impossible
11:08	jnettlet	test with a generic 3.14.14 kernel and get back to me
11:09	curlymo	we ofc need btrfs lz4
11:10	jnettlet	then it is up to your kernel developers to test and fix these things.
11:10	jnettlet	I am looking at the repo and there 10 gpu patches on top of my kernel
11:10	jnettlet	how can a sane person make that many changes and then come and complain to me that my kernel is causing problems?
11:11	curlymo	i was not saying that
11:11	jnettlet	if xbian wants to do their own thing that is great, but then they need to provide support for it
11:12	jnettlet	I don't have the bandwidth to cleanup their messes
11:13	curlymo	i just asked it you were aware of the issue that could occur with 3.14.14. An answer, "no please test with with a clean kernel" would have been sufficient.
11:15	curlymo	but i will get back to you when i have test results from a clean compilation
11:54	R0nd	I'm getting this error when compiling latest xbmc, any idea what went wrong?
11:54	R0nd	LinuxRendererGLES.cpp:83:32: error: 'void* (* eglCreateSyncKHR)(EGLDisplay, EGLenum, const EGLint*)' redeclared as different kind of symbol
11:54	R0nd	In file included from /usr/local/include/EGL/egl.h:327:0,
11:54	R0nd	from /media/esata/xbmc/xbmc/windowing/egl/WinSystemEGL.h:28,
11:54	R0nd	from /media/esata/xbmc/xbmc/windowing/WindowingFactory.h:39,
11:54	R0nd	from LinuxRendererGLES.cpp:45:
11:55	R0nd	usr/local/include/EGL/eglext.h:144:31: error: previous declaration of 'void* eglCreateSyncKHR(EGLDisplay, EGLenum, const EGLint*)'
11:56	R0nd	there are duplicate declarations of several functions in eglext.h and xbmc sources, maybe my xbmc configuration is wrong?
12:59	Humpelstilzchen	R0nd: what configure arguments did you use?
12:59	R0nd	--disable-vdpau --disable-vaapi --enable-gles --disable-pulse --disable-projectm --enable-codec=imxvpu --disable-openmax --disable-x11 --disable-xrandr --disable-gl --disable-sdl
13:03	Humpelstilzchen	thats indeed a new change
13:04	R0nd	I tried commenting out the duplicates in eglext.h, but xbmc crashes that way
13:06	Humpelstilzchen	my xbmc doesn't have these yet
13:08	R0nd	what commit are you on?
13:08	Humpelstilzchen	4cbf9e0
13:13	Humpelstilzchen	this might be a bug, depends on the reason why the define EGL_KHR_reusable_sync is set
13:50	curlymo	jnettlet, i did a clean compile of your kernel but: [ 62.177371] [galcore]: GPU[0] hang, automatic recovery.
13:50	curlymo	[ 82.177488] [galcore]: GPU[0] hang, automatic recovery.
13:50	curlymo	[ 102.177603] [galcore]: GPU[0] hang, automatic recovery.
13:50	curlymo	[ 122.177743] [galcore]: GPU[0] hang, automatic recovery.
13:51	curlymo	[ 142.177839] [galcore]: GPU[0] hang, automatic recovery.
13:55	R0nd	huh, I've checked out the same commit but the error didn't go away
14:30	Humpelstilzchen	R0nd: done make clean?
14:31	R0nd	yep
14:33	R0nd	are you using the same configuration options?
14:34	Humpelstilzchen	I think so, they look familiar
14:35	Humpelstilzchen	might a broken header
14:36	Humpelstilzchen	do you have any duplicate headers? One in /usr/local/include that is also in /usr/include
14:38	R0nd	doesn't look like it
14:38	Humpelstilzchen	where did you put your downloaded imx-libs headers?
14:54	R0nd	tbh I don't remember
14:55	R0nd	what's the filename I should look for?
15:09	Humpelstilzchen	R0nd: something like imx-vpu-3.10.17 and gpu-viv-bin-mx6q-3.10.17
15:10	Humpelstilzchen	one of them or both did come with headers
15:12	R0nd	imx-vpu headers are in /usr/include
15:12	Humpelstilzchen	and the /usr/local headers?
15:14	R0nd	there's EGL, GLES etc in /usr/local/include
15:36	curlymo	jnettlet, any idea what could cause the gpu hangs?
15:38	jnettlet	curlymo, considering nobody is seeing them but xbian, my guess is something they have done to xbmc
15:39	wrexem	Did you guys see Hummingboard up on Hackaday?
15:39	wrexem	http://hackaday.com/2014/09/22/freescale-and-texas-instruments-goodies-and-world-maker-faire/
15:41	jnettlet	very cool