[borderite]

Cool! The requested dump is available at:

https://www.dropbox.com/s/095rl7jhem99b7l/dump.bin?dl=0

The output from from "vcgencmd version" is:

Code:

May  4 2017 15:58:39
Copyright (c) 2012 Broadcom
version 809412fa5f5f7d88833e076d71dc329367441601 (clean) (release)

[snipehuntr]

i also have a vizio smarttv with same issue with my kodi pin rPi3 w/ raspbian. (all is up2date)
vizio remote volume "hangs" kodi. with an incessant and annoying audio squelch/chip/burp type sound...electronic hiccups?
disabling cec, does not seem to eliminate the issue. my cec is disbled, yet god forbid i touch the vizio remote.

i'm new to kodi and not native to linux, but can follow directions decently, if it'll help.

[borderite]

@popcornmix

I am wondering if you have had a chance to look at the memory dump I passed to you. Have you found anything useful for resolving the issue? Please let me know if you need something else.

Borderite

[snipehuntr]

just in case its helpful to anyone...i think you guys are past this point, but here you go...

I have a vizio TV and Vizio SoundBar.
Spectrum/TWC is cable provider.

if I use either the vizio remote or spectrum all-in-one remote, kodi hangs up.
using the sound bar remote has no impact.
cec is disabled in kodi.

[popcornmix]

I am wondering if you have had a chance to look at the memory dump I passed to you. Have you found anything useful for resolving the issue? Please let me know if you need something else.

Sorry - the tool that analyses the memory dump hasn't been used for a long time and currently isn't working.
I've spent a while trying to get information out of it but so far haven't succeeded.

It is something I'd like to get working, but it may be quicker if I give you a test firmware that tries to capture the information I need through other means.

[popcornmix]

@borderite can you use start_db.elf / fixup_db.dat from this zip file:
https://drive.google.com/uc?id=0B-6zmEDJ...t=download

Rename to start.elf / fixup.dat, reboot and provoke the hang.
Report output of "vcdbg log assert"
Hopefully that will give an extra line in log showing the calling function of rtos_latch_get_real.

[borderite]

@popcornmix Thanks for your reply. Unfortunately, "vcdbg log assert" in the new setup only yields the message "No messages available". But I have found a strange thing by accident: If I push the channel-up or channel-down button of my TV remote before I touch the volume-up or volume-down button first time after reboot, then Kodi does not freeze. In Libre Elec, the channel-up and channel-down buttons respectively move the pointer to the item at the upper and lower end in the menu. So, the channel buttons seem to send signals to Kodi via CEC. This may mean that the RPi side processes the volume-up and volume-down signals sent from TV skipping some steps, which the RPi side does not skip when it receives a channel change signal.

[popcornmix]

@popcornmix Thanks for your reply. Unfortunately, "vcdbg log assert" in the new setup only yields the message "No messages available".

Are you sure you used start_db.elf/fixup_db.dat (renamed to start.elf/fixup.dat) as described?
It sounds like start.elf/fixup.dat were used directly.

[borderite]

Sorry, it seems that I made a mistake somewhere. I have re-inspection the experiment again and got outputs from "vcdbg log assert" this time. Please find it at:

http://sprunge.us/AVgF

[katsup]

There is a way to tell Kodi to ignore specific remote press in the remote.xml file. I have done this in the past on an older system I was using.

You can try this as a temp fix till the issue is resolved.

[popcornmix]

Sorry, it seems that I made a mistake somewhere. I have re-inspection the experiment again and got outputs from "vcdbg log assert" this time. Please find it at:

http://sprunge.us/AVgF

Had you definitely had the firmware lockup (e.g. vcgencmd version not responding) as you had in original failures?
The assert:

Code:

204234.257: assert( (interrupt_save & (1<<30)) || ((int)_tx_thread_system_state < 0) ) failed; ../../../../../vcfw/rtos/threadx/rtos_threadx_latch.c::rtos_latch_get_real line 99 rev 809412f
vcdbg_ctx_get_dump_stack: dump_stack failed

Doesn't appear in new assert log, so I'm not getting the additional line I was hoping for.

[borderite]

@popcornmix Hmmm, I have just re-done the experiment again. This time, the assert log had a few more lines, including the one you quoted in your message. It is at:

http://sprunge.us/BZFF

I verified that "vcgencom version" did not respond.

[popcornmix]

Okay, latest log shows the call was from cache_flush which didn't narrow it down enough.
So I returned to digging through the memory dump from earlier and I did manage to get some info out.

We have had an undefined instruction exception caused by calling a null function pointer.
I can see where the null function pointer is called from and have added code to protect that.
Can you test this firmware: https://drive.google.com/uc?id=0B-6zmEDJ...t=download

Now, I still don't know why the function pointer is null, so there may still be an issue that needs addresses but this should stop the firmware from crashing.
Can you report what the behaviour is now?

[borderite]

@popcornmix I am afraid that the new firmware still bears the freeze problem in the same way. I, however, see one item has disappeared from the assert log. The second last item in the previous log:

Code:

019411.881: assert( logical_address < CEC_AllDevices_eUnRegistered && physical_address != CEC_CLEAR_ADDR ) failed; ../../../../../middleware/hdmi/cec.c::hdmi_cec_update_topology line 2534 rev b8cdd5a
vcdbg_ctx_get_dump_stack: dump_stack failed

no longer showed up. The new assert log is available at:

http://sprunge.us/GHNE

[borderite]

One more finding. Using channel up or down before doing volume up or down does not work anymore.