firmware: latest commit breaks omxplayer (or GPU)

[jusii]

Just pulled latest firmware 998327d2ee58c9a021883167207806a7624aa7bf and while playing short videos with omxplayer they play fine for few times but after that omxplayer won't even start. Attached omxplayer.log

Reverting to 704ae38d749579a9fca20da8d7e48ce5a86c6ea1 fixed it.

Also noticed that start.elf grew from 2654584 to 3537592 with latest commit

Linux firstviewpi 3.18.9-arm7+ #11 SMP PREEMPT Wed Mar 25 08:48:23 EET 2015 armv7l GNU/Linux

git rev-parse HEAD (kernel)
780e68130fba82a525b89e85f051c91b7a508e52

config.txt

gpu_mem=128
hdmi_force_hotplug=1
disable_overscan=1
display_rotate=0
framebuffer_depth=32
framebuffer_ignore_alpha=1
boot_delay=2

omxplayer - Commandline multimedia player for the Raspberry Pi
Build date: Thu, 19 Mar 2015 01:49:46 +0000
Version : 7c752d3 [master]
Repository: https://github.com/popcornmix/omxplayer.git

09:46:10 T:18446744072718328082 DEBUG: DllBcm: Using omx system library
09:46:10 T:18446744072718330441 DEBUG: DllOMX: Using omx system library
09:46:10 T:18446744072718331953 DEBUG: DllAvFormat: Using libavformat system library
09:46:10 T:18446744072718337841 DEBUG: DBus connection succeeded
09:46:10 T:18446744072718340680 DEBUG: Keyboard: DBus connection succeeded
09:46:10 T:18446744072718341027 DEBUG: OMXThread::Create - Thread with id -1305480144 started
09:46:10 T:18446744072718341216 DEBUG: DllAvUtilBase: Using libavutil system library
09:46:10 T:18446744072718341347 DEBUG: DllAvCodec: Using libavcodec system library
09:46:10 T:18446744072718341424 DEBUG: DllAvFormat: Using libavformat system library
09:46:10 T:18446744072718425945 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.clock input port 80 output port 81 m_handle 0x178f8c0
09:46:10 T:18446744072718426455 DEBUG: OMXClock::OMXStop
09:46:10 T:18446744072718426648 DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
09:46:10 T:18446744072718426985 DEBUG: DllAvUtilBase: Using libavutil system library
09:46:10 T:18446744072718427043 DEBUG: DllAvCodec: Using libavcodec system library
09:46:10 T:18446744072718427089 DEBUG: DllAvFormat: Using libavformat system library
09:46:10 T:18446744072718429090 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.video_decode input port 130 output port 131 m_handle 0x1790df0
09:46:10 T:18446744072718430451 DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.video_decode) - port(130), nBufferCountMin(1), nBufferCountActual(60), nBufferSize(81920), nBufferAlignmen(16)
09:46:10 T:18446744072718440849 ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.video_decode - OMX_ErrorInsufficientResources, insufficient resources
09:46:10 T:18446744072718449029 ERROR: COMXCoreComponent::FreeInputBuffers WaitForCommand:OMX_CommandPortDisable failed on OMX.broadcom.video_decode omx_err(0x80001000)
09:46:10 T:18446744072718449741 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.video_decode handle 0x1790df0
09:46:10 T:18446744072718450065 DEBUG: OMXClock::OMXStop
09:46:10 T:18446744072718463266 DEBUG: OMXThread::Run - Exited thread with id -1305480144
09:46:10 T:18446744072718463817 DEBUG: OMXThread::StopThread - Thread stopped
09:46:10 T:18446744072718466154 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.clock handle 0x178f8c0

[popcornmix]

Can you try with gpu_mem=128

[jusii]

That's what I have there:

Or did you mean even more?

config.txt

gpu_mem=128
hdmi_force_hotplug=1
disable_overscan=1
display_rotate=0
framebuffer_depth=32
framebuffer_ignore_alpha=1
boot_delay=2

[popcornmix]

Can you try more?

OMX.broadcom.video_decode - OMX_ErrorInsufficientResources, insufficient resources

usually means a lack of gpu memory. A sample of a video that fails to play could be useful.

[reufer]

I observe the same behavior, but with rpihddevice, the RPi VDR output plugin. The issue is seen after some time of zapping through the channels list (by a test script, which triggers a channel switch every few seconds). For me, it looks like a memory leak within the GPU.

[deborah-c]

@reufer: is this with 998327, or with the latest firmware? There were some problems in 998327 with codec resource tracking, which as far as I'm aware are now fixed.

[reufer]

@deborah-c: It's with the latest firmware.

[deborah-c]

Thank you. I'll try to take a look in the morning.

[popcornmix]

@jusii are you seeing this with latest firmware?

[jusii]

@popcornmix looks good with latest firmware!

Thanks!

[popcornmix]

@reufer Any way to reproduce your problem without external TV hardware?
Can you trigger the problem from recordings?

[reufer]

@popcornmix: I'll modify the script to repetitively replaying a record and let you know the result.

Yesterday I reverted the firmware to an early version of January and ran the test overnight. After approx. 12hrs of zapping all the GPU memory was eaten up, so the root cause could be somewhere else.

The issue can be forced by converting a big number of glyphs (approx. 6000 in my test) to OpenVG paths, however 'vcdbg reloc' reports a largest free block of 117MB. (see #406) I'm using a Raspberry Pi 1, Model B with 256MB fix allocated for the GPU.

[popcornmix]

Is the memory permanently lost, or only until your application exits?
E.g. if you quit your application and restart it, does it work okay, or does it require a reboot?

[reufer]

The memory seems to be lost permanently, I have to reboot to get it running again.

[popcornmix]

Okay, can you post output of

vcgencmd cache_flush && sudo vcdbg reloc
sudo vcdbg log msg

After you application has exited. It might give some clues what went wrong.

[reufer]

the log says:

[...]
3845715.991: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
3846354.960: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
3847005.045: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
2116330.985: *** No KHAN handle found for pid 18466

and the memory looks like this: http://reufer.dyndns.org/temp/reloc_after_flush.txt

[popcornmix]

Seems to be a n OpenVG problem. Nothing has changed in firmware with OpenVG for at least a year.
So, I assume this has always happened and isn't related to a firmware update?

[reufer]

Yes, it's most probably not related to a recent update and might be an issue since a long time. I recently added advanced OpenVG-support and just started extensive testing, so the problem might even exist since the very beginning. Is there a place/person to get support in this area?

[popcornmix]

Unfortunately we don't have an OpenVG expert anymore. However the "No KHAN handle for pid" message is more related to the communication with OpenVG than the internals of it, so we may be able to fix that if we had a reproducible test case.

It would be useful if you could cut down your application to just do the OpenVG GUI stuff (and not the video stuff), and hopefully that would fail sooner. Ideally make an small application like /opt/vc/src/hello_pi/hello_tiger that if left to run for some time produces the failure.

It would be best to create a new github issue, as this seems to be an OpenVG issue, and is not related to updated firmware or omxplayer, so reporting this in someone else's issue is just confusing.

[popcornmix]

I'll close this issue. Please continue discussion in #406.

I'm not sure when someone will be able to investigate, but if you have a link to what's needed available (e.g some source and makefile, or an archive containing the files needed to provoke the issue) then when someone has some time they'll be able to investigate.