Login at Kodi Home

Milhouse · 2018-01-09, 02:53

Weekly Linux 4.15-rc7 build #0108x: RPi / RPi2

Changes:

Code:
Replace out-of-tree RTL8192CU driver with in-tree kernel driver

Packages disabled/not included:

Code:
DVB Driver Addons

Packages added/updated:

Code:
RTL8192DU

RTL8192EU

RTL8188EU

RTL8812AU

RTL8192CU (in-kernel)

Milhouse · (This post was last modified: 2018-01-09, 03:11 by Milhouse.)

(2018-01-09, 01:44)germa18 Wrote: videoplayer is unusable with this build #0108, i launch one video and it starts the video and stuck with the first image, when i try to close the video, i just have a black screen and i cannot due anything on the screen
https://drive.google.com/file/d/1ryOoiec...sp=sharing

(2018-01-09, 02:35)Sholander Wrote: Same here on RPi3. Seems like some (USB) disk problem; video player stops and after reboot no picture with USB disk connected. Booting without disk it boots OK, but video player still not playing videos from reconnected disk...

This seems to be quite difficult to reproduce - so far I have had one video (VC-1, MMAL, streamed over nfs://) that froze at start of playback (requiring kodi.bin to be restarted) but in every other test this video (and all others tested, streamed over nfs://, smb:// and local) plays normally.

Are you having this problem with Live TV, or is it all videos? Any particular non-standard video settings (deinterlace, sync audio, adjust refresh rates etc.)?

Can you try the firmware from #0107 with #0108 (copy bootcode.bin, start.elf and fixup.dat from #0107 to #0108)?

Otherwise this could be a 4.14.12 kernel issue resulting from the Meltdown changes - please try 4.15-rc7 and see if it's any better/worse/same.

smp1 · 2018-01-09, 03:39

(2018-01-09, 03:10)Milhouse Wrote: 4.14.12 kernel issue resulting from the Meltdown changes

Isn't KPTI supposed to be disabled for RPi?

Milhouse · (This post was last modified: 2018-01-09, 04:22 by Milhouse.)

(2018-01-09, 03:39)smp1 Wrote:
(2018-01-09, 03:10)Milhouse Wrote: 4.14.12 kernel issue resulting from the Meltdown changes
Isn't KPTI supposed to be disabled for RPi?

Yes, however the KPTI changes which are present throughout the kernel may be producing unexpected/unintended results even when "disabled".

Edit: This is worth a read: http://kroah.com/log/blog/2018/01/06/meltdown-status/

I honestly don't know if the KPTI changes will cause issues on ARM, but given the nature of the issue and the solution, maybe it's possible. Of course, the video issues might be something completely unrelated - I've no idea at this stage as it seems very hard to reproduce (for me, anyway). There didn't seem to be any obvious Kodi changes in #0108, so the most likely candidates are either firmware or kernel.

Milhouse · (This post was last modified: 2018-01-09, 05:38 by Milhouse.)

Yes there's something wrong with #0108 - I'm starting to experience frozen video at start of playback more often now (though no idea why not earlier, it's kind of random).

It doesn't appear to be firmware, as I tried #0107 firmware and the issue persists.

I've created #0108b RPi2 which is the same as #0108 but with a 4.14.10 kernel in place of 4.14.12.

My initial testing suggests #0108b does not have the video playback issues that #0108 does. Please test #0108b and confirm.

Milhouse · 2018-01-09, 06:18

I've created build #0108c RPi2 which is based on 4.14.12 but without the 6 new vcsm commits shown in #0108:

(2018-01-09, 00:47)Milhouse Wrote:

kernel 4.14.y:
New commits in this build:
vcsm: Define cache operation constants in user header (df265b51)

vcsm: Support for finding user/vc handle in memory pool (9f5076a7)

vcsm: Unify cache manipulating functions (1a1ad1fe)

vcsm: Fix obscure conditions (86d5ad8f)

vcsm: Fix memory leaking on clean_invalid2 ioctl handler (63e3fac5)

vcsm: Describe the use of cache operation constants (8d806585)

Build #0108c seems OK to me - it would be good to know if those having problems with #0108 have the same issues with #0108c, or not.

@popcornmix could the vcsm commits be the problem? It's possible I just haven't managed to reproduce the issue with #0108c however a new 4.14.12 build that included the vcsm commits froze on the first video, while I'm yet to experience any freeze with #0108c after 20 videos.

**popcornmix** · 2018-01-09, 11:11

(2018-01-09, 06:18)Milhouse Wrote: @popcornmix could the vcsm commits be the problem? It's possible I just haven't managed to reproduce the issue with #0108c however a new 4.14.12 build that included the vcsm commits froze on the first video, while I'm yet to experience any freeze with #0108c after 20 videos.

It is certainly possible. I added the vcsm commits for further testing as they are in a linux PR that I was considering merging.
As the vcsm commits affect cache flushing then intermittent (depending on the state of the cache) failures are possible.

Can you confirm the type of video that has the issue?
There will be much more cache flushing from hevc or software decoded video than hardware (mmal).
Enabling omxplayer will probably bypass the cache flushing completely so I might guess it doesn't have the issue.

Chudley · 2018-01-09, 14:43

It looks like the VCSM commits are responsible.

On the latest build, playback of live interlaced SD mpeg2 content via tvheadend triggers the issue without playback starting. The below relates to progressive H264 playback which works fine until playback is stopped, at which point the same freeze occurs, and the same backtrack is generated. This seems to occur directly in relation to code touched by one of the VCSM commits?

Quote:[ 194.355142] Unable to handle kernel paging request at virtual address 5d37f000
[ 194.355155] pgd = a9f14000
[ 194.355161] [5d37f000] *pgd=28ed2835, *pte=00000000, *ppte=00000000
[ 194.355192] Internal error: Oops: 2817 [#1] SMP ARM
[ 194.355233] Modules linked in: hci_uart bluetooth ecdh_generic 8021q brcmfmac brcmutil cfg80211 rfkill bcm2835_gpiomem fixed
[ 194.355310] CPU: 3 PID: 533 Comm: vc.ril.video_de Not tainted 4.14.12 #1
[ 194.355329] Hardware name: BCM2835
[ 194.355346] task: ae193840 task.stack: a8f20000
[ 194.355375] PC is at v7_dma_inv_range+0x30/0x48
[ 194.355400] LR is at clean_invalid_mem_2d+0x80/0xc8
[ 194.355419] pc : [<80117dd8>] lr : [<8056ca28>] psr: 88000013
[ 194.355439] sp : a8f21de8 ip : a8f21e10 fp : a8f21e0c
[ 194.355457] r10: 00000000 r9 : 00000000 r8 : 00100000
[ 194.355476] r7 : 00000001 r6 : 80117da8 r5 : 00000001 r4 : 5d300000
[ 194.355497] r3 : 0000003f r2 : 00000040 r1 : 5d400000 r0 : 5d37f000
[ 194.355520] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 194.355542] Control: 10c5383d Table: 29f1406a DAC: 00000055
[ 194.355562] Process vc.ril.video_de (pid: 533, stack limit = 0xa8f20210)
[ 194.355584] Stack: (0xa8f21de8 to 0xa8f22000)
[ 194.355606] 1de0: ae053f00 5d300000 00100000 00000001 0000000f ffffe000
[ 194.355635] 1e00: a8f21e3c a8f21e10 8056d180 8056c9b4 00000001 a8f21e20 00000000 ae053f00
[ 194.355664] 1e20: 00000000 ada10c80 80ec7ab8 a8f20000 a8f21f0c a8f21e40 8056f37c 8056d0b4
[ 194.355693] 1e40: ae053f00 a8f21e50 80149338 80148f0c 00000064 a8f21e54 a8f21e54 a8f21e5c
[ 194.355721] 1e60: 00001000 5d300000 00100000 6f34b000 ae18ea80 00000e08 00000000 00000000
[ 194.355749] 1e80: 00000000 ffffffff ae18ea80 00000001 00000009 00000002 6f34be08 00000001
[ 194.355783] 1ea0: a8f20000 6f34be08 a8f21f5c a8f21eb8 8019421c 80192134 ffffffff af117780
[ 194.355817] 1ec0: a8f21eec a8f21ed0 80123ed0 801cecf4 ffffe000 00000007 00000100 00000000
[ 194.355852] 1ee0: a8f21f54 550fed24 adda5d70 aeb91f00 00000003 550fed24 a8f20000 00000000
[ 194.355887] 1f00: a8f21f7c a8f21f10 8027dfd0 8056e8f0 80901eb4 0000000a 80e8f940 80e85e10
[ 194.355922] 1f20: 80d4b378 80e02080 8016d5ec ffffe000 00000000 8028a6ec 5d300000 7585cf24
[ 194.355957] 1f40: 00000003 800c4963 550fed24 a8f20000 a8f21f6c aeb91f01 aeb91f00 00000003
[ 194.355991] 1f60: 800c4963 550fed24 a8f20000 00000000 a8f21fa4 a8f21f80 8027e714 8027df2c
[ 194.356026] 1f80: 5d300000 7585cf24 7585cf24 00000036 801084c4 a8f20000 00000000 a8f21fa8
[ 194.356061] 1fa0: 80108320 8027e6dc 5d300000 7585cf24 00000003 800c4963 550fed24 00100000
[ 194.356096] 1fc0: 5d300000 7585cf24 7585cf24 00000036 566defec ffffffec 00000000 550feecc
[ 194.356131] 1fe0: 7585ce30 550fecf4 7584aefc 7500514c 28000010 00000003 00000000 00000000
[ 194.356157] Backtrace:
[ 194.356191] [<8056c9a8>] (clean_invalid_mem_2d) from [<8056d180>] (clean_invalid_resource+0xd8/0x1a4)
[ 194.356229] r9:ffffe000 r8:0000000f r7:00000001 r6:00100000 r5:5d300000 r4:ae053f00
[ 194.356268] [<8056d0a8>] (clean_invalid_resource) from [<8056f37c>] (vc_sm_ioctl+0xa98/0x15a8)
[ 194.356304] r9:a8f20000 r8:80ec7ab8 r7:ada10c80 r6:00000000 r5:ae053f00 r4:00000000
[ 194.356344] [<8056e8e4>] (vc_sm_ioctl) from [<8027dfd0>] (do_vfs_ioctl+0xb0/0x7b0)
[ 194.356379] r10:00000000 r9:a8f20000 r8:550fed24 r7:00000003 r6:aeb91f00 r5:adda5d70
[ 194.356407] r4:550fed24
[ 194.356434] [<8027df20>] (do_vfs_ioctl) from [<8027e714>] (SyS_ioctl+0x44/0x68)
[ 194.356469] r10:00000000 r9:a8f20000 r8:550fed24 r7:800c4963 r6:00000003 r5:aeb91f00
[ 194.356497] r4:aeb91f01
[ 194.356525] [<8027e6d0>] (SyS_ioctl) from [<80108320>] (ret_fast_syscall+0x0/0x28)
[ 194.356560] r9:a8f20000 r8:801084c4 r7:00000036 r6:7585cf24 r5:7585cf24 r4:5d300000
[ 194.356594] Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
[ 194.356622] ---[ end trace a47d709b6aab560c ]---

Milhouse · 2018-01-09, 15:07

(2018-01-09, 11:11)popcornmix Wrote: Can you confirm the type of video that has the issue?
There will be much more cache flushing from hevc or software decoded video than hardware (mmal).
Enabling omxplayer will probably bypass the cache flushing completely so I might guess it doesn't have the issue.

Testing #0108 with OMX disabled, MMAL enabled, RPi3, VC1 and MPEG codec licences.

VC-1 video is a problem, as is h264 (eg. 720P).

Video will either fail to start (the GUI will freeze without any video appearing) or a few frames of video may appear and then freeze.

If I enable OMX and disable MMAL, then the VC-1 and h264 videos playback without any issue, so it looks like omxplayer does not have this issue.

Aux_ · (This post was last modified: 2018-01-09, 16:09 by Aux_.)

(2018-01-09, 03:10)Milhouse Wrote: Are you having this problem with Live TV, or is it all videos? Any particular non-standard video settings (deinterlace, sync audio, adjust refresh rates etc.)?

Live TV is not working properly on #0108, it runs for a few minutes and then freezes.
You can not do anything by remote only doing hard reset helps,
but in #0108c everything works fine, both live TV and movies.

alannmills · 2018-01-09, 18:19

Running build From Jan 5th build results in no sound when video is played (or liveTV), but there is GUI sound

http://ix.io/DR6

The previous build from Jan 4th works correctly

Working

LibreELEC-RPi.arm-9.0-Milhouse-20180104223802-%230104-gf7875a1

Not Working

Has GUI sounds, but playing any video results in no sound

LibreELEC-RPi.arm-9.0-Milhouse-20180105221510-#0105-g978b00c

Milhouse · 2018-01-09, 18:57

(2018-01-09, 18:19)alannmills Wrote: Running build From Jan 5th build results in no sound when video is played (or liveTV), but there is GUI sound

Are you using passthrough audio at all?

alannmills · 2018-01-09, 19:55

(2018-01-09, 18:57)Milhouse Wrote:
(2018-01-09, 18:19)alannmills Wrote: Running build From Jan 5th build results in no sound when video is played (or liveTV), but there is GUI sound

Are you using passthrough audio at all?

I have the same settings from Jan 4 to Jan 5.
Audio Device is set for PI:HDMI, Output configuration is fixed, but optimized produces same results
It doesn't matter if I set it to 2.0, or 5.1 on the Jan 5 build, the only sound is GUI
There is nothing showing under passthrough settings (no option to set anything)
For what it is worth, the HDMI output lead from PI is plugged into soundbar, and from there it goes into the Vizio TV

Let me know if you need anything else

**doug** · 2018-01-09, 20:18

@ksooo, @da-anda

Hi,
Here's a large crash log from Milhouse's last debug build. I simply watched a previously recorded program and the crash happened a few hours later. That is the way it always seems to happen.

https://drive.google.com/file/d/1khkLLOF...sp=sharing

If I can provide or do anything else, let me know.

Milhouse · 2018-01-09, 20:28

(2018-01-09, 20:18)doug Wrote: Here's a large crash log from Milhouse's last debug build. I simply watched a previously recorded program and the crash happened a few hours later. That is the way it always seems to happen.

Thanks @doug, although build #0102 isn't a debug-enabled build - it's a non-debug build. Build #0106d RPi2 is the last debug-enabled build. Or did you upload the wrong crash log?

There is some potentially useful detail in the #0102 crashlog, which points towards the logger component but I'll leave it to @ksooo and @da-anda if they think a debug-enabled crash log is required.