please, could you tell me how to?
Change is non-persistent. If you reboot the system, it's already gone.
Unfortunately it froze.
That's not that surprising. As I said, CEC and Cedrus doesn't have anything in common, except one shared clock.
In any case, I observed freezing problem already in the past on OrangePi 3 (non LTS), but not on the other boards. I went over many things several times, but I couldn't find anything important. Search continues...
That's not that surprising. As I said, CEC and Cedrus doesn't have anything in common, except one shared clock.
One thing I tried was turning off CEC from the TV side, and well that really pissed off the device (5-6 LOW_DRIVE warnings every 6 seconds) and it actually froze during menu navigation pretty quickly. I'm testing now with CEC turned off on the Kodi side to see if that has any actual influence as reported earlier. I feel like I have already been there, the next thing will be CEC off on both ends.
Whatever the cause it is locking up everything (USB keyboard, serial console, network, etc).
At least with the original OPi3, it was possible to crash the system just by rapidly switching between playing different files. Can you trigger it this way? If we find some pattern, it will be easier to find the solution.
frakkin64 can you confirm, that with new CEC patches, you don't see messages such as:
cec-dw_hdmi: message 10 timed out
dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
It doesn't matter if CEC on TV is enabled or not.
frakkin64 can you confirm, that with new CEC patches, you don't see messages such as:
cec-dw_hdmi: message 10 timed out
dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
It doesn't matter if CEC on TV is enabled or not.
If CEC is on from the device side, yes. If CEC is off from the device side, no. But it's not frequent, usually a few times at start up, and then throughout usage.
Can you give me your exact messages? I'm interested in numbers in them.
Anyway, I went through CedarX vendor lib and found some differences regarding MPEG2 setup. You can try this kernel patch:
http://ix.io/4Fsv However, I couldn't find any real world difference. Maybe something can be done on ffmpeg side.
Can you give me your exact messages? I'm interested in numbers in them.
Generally this is what I see.
Sep 05 13:51:00 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:01 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:01 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:02 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVESep 05 13:51:02 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:02 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:03 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:03 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:17 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:18 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:18 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Sep 05 13:51:18 LibreELEC kernel: dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
My last test was to try and repeat what OP reported, turning off CEC from the Kodi side. And the device still froze, so my feeling is CEC is not the cause.
Interesting, this was on the serial console:
[139292.752154] SError Interrupt on CPU1, code 0x00000000bf000000 -- SError
[139292.752185] CPU: 1 PID: 856 Comm: EPGUpdater Not tainted 6.5.0 #1
[139292.752202] Hardware name: OrangePi 3 LTS (DT)
[139292.752210] pstate: 80000000 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[139292.752226] pc : 0000000000ed2d40
[139292.752231] lr : 0000000000ed2d04
[139292.752236] sp : 0000ffff291fe3a0
[139292.752241] x29: 0000ffff291fe690 x28: 000000000ac008e8 x27: 0000000001a17858
[139292.752266] x26: 0000000000000000 x25: 0000000000000001 x24: 000000000ac00cf0
[139292.752286] x23: 000000000ac00cd8 x22: 000000000ac008e0 x21: 000000000ac00ca0
[139292.752307] x20: 0000000001a17858 x19: 0000ffff291fe4f0 x18: 00000000000007e7
[139292.752327] x17: 00a3d70a3d70a3d6 x16: 051eb851eb851eb0 x15: 028f5c28f5c28f5c
[139292.752348] x14: 051eb851eb851eb8 x13: 8f5c28f5c28f5c29 x12: 2ce33e6c02ce33e7
[139292.752369] x11: 000000000000016d x10: a3d70a3d70a3d70b x9 : 0000000000000064
[139292.752389] x8 : 0000000000000190 x7 : 00000000000000f9 x6 : 00000000000001ea
[139292.752408] x5 : 0000000000000003 x4 : 0000000000000004 x3 : 0000000000000001
[139292.752426] x2 : 0000000000000009 x1 : 0000ffff291fe4f0 x0 : 00000000015c7820
[139292.752449] Kernel panic - not syncing: Asynchronous SError Interrupt
[139292.752456] CPU: 1 PID: 856 Comm: EPGUpdater Not tainted 6.5.0 #1
[139292.752470] Hardware name: OrangePi 3 LTS (DT)
[139292.752476] Call trace:
[139292.752481] dump_backtrace+0x9c/0xd8
[139292.752515] show_stack+0x14/0x1c
[139292.752535] dump_stack_lvl+0x44/0x58
[139292.752557] dump_stack+0x14/0x1c
[139292.752574] panic+0x2f0/0x34c
[139292.752588] nmi_panic+0x68/0x6c
[139292.752601] arm64_serror_panic+0x68/0x78
[139292.752614] do_serror+0x38/0x68
[139292.752626] __el0_error_handler_common+0x2c/0x6c
[139292.752649] el0t_64_error_handler+0xc/0x14
[139292.752668] el0t_64_error+0x14c/0x150
[139292.752683] SMP: stopping secondary CPUs
[139293.926932] SMP: failed to stop secondary CPUs 0-2
[139293.926942] Kernel Offset: disabled
[139293.926946] CPU features: 0x00000004,00000000,0000400b
[139293.926954] Memory Limit: none
[139294.336367] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---Here is perhaps something more interesting, built a kernel with kgdb/kdb enabled.
IDK file system causes crash. Maybe low memory situation. Can you also please enable KASAN? It should print error report in dmesg whenever memory issue is detected.
IDK file system causes crash. Maybe low memory situation. Can you also please enable KASAN? It should print error report in dmesg whenever memory issue is detected.
It's a bit all over the place, SError, then unimplemented instruction, random freezing. Feels like a memory problem. I'll compile with KASAN as well and see what happens.
turning off CEC from the Kodi side. And the device still froze, so my feeling is CEC is not the cause.
I am sorry to further muddy the waters, but what version of LE were you running?
This is just anecdotal, and not any kind of proof, but there was one of my Opi3LTS' that was also locking up even with CEC off. I had been running the recent v11 nightlies on it. I had actually written "flaky" on it with a marker and pretty much tossed it in the corner. But just for S&G I loaded the v11 nigthly from January 9th on it (the same version that has been running on another Opi3Lts for months without freezing).
and now the same "flaky" board that wouldn't last more than 6 hours with a recent nightly on it has been running nonstop for over 48 hours with an old nightly from January. (and in both of these cases, CEC was OFF).
I will install your kgdb/kdb kernel and keep my serial terminal recording...
I am sorry to further muddy the waters, but what version of LE were you running?
I'm running LE12 nightlies. I don't think the device is defective, my guess is it is some clock/timing/voltage issue that is marginal.
I have one possible explanation - IOMMU. H6 driver doesn't have locking implemented in some functions, but other do. Without that, race conditions are possible when allocating and freeing memory during video decoding and rendering.
Updated patches are here: https://github.com/jernejsk/Libre…224ebdee7aa57b1 They should apply to both, LE11 and LE12, branches.
Let me know if you need builded image.
Updated patches are here: https://github.com/jernejsk/Libre…224ebdee7aa57b1
I made a v11 image with these patches, and let it sit idle overnight with the default configuration (so CEC was enabled). It locked up after a little more than 8 hours.
Thanks for testing. Can you also try with CONFIG_SUN50I_IOMMU disabled? Just to make sure IOMMU is not at fault.
CONFIG_SUN50I_IOMMU
where do i find that? is it in one of the patch files? or kernel config?
