Posts by milhouse

tomtomclub thanks, that's another Kodi and/or addon bug. Perhaps I should have made this clear - the important aspect of #0614c (and the other builds I've posted in this thread) is the kernel behaviour, in particular GLK and AMD support, I'm not trying to create another "general" support thread. If you want to report a bug with kodi master please test the #0614 build that I've posted in the kodi forum, reproduce the issue and post a debug log/crash log as appropriate in the kodi forum thread. Thanks again.

Thanks, sounds promising - I've dropped the "i915.glkhdmi=2" workaround from the 4.17 branch, and added the "V2 Quirks" patch.

Quote from porkchop999

Strange, with this build Resolution, Refresh rate and Blank other displays displays are greyed out

Arghh... OK, that's a new Kodi bug introduced in #0614, which has now been reverted with PR14049.

I've uploaded #0614c which includes PR14049 as a replacement for #0614b: libreelec-generic.x86_64-9.0-milhouse-20180615154459-#0614c-g83c436f.tar

This is the patch I'm testing, which applies on top of the existing 4.17 branch: http://ix.io/1doe

Quote from eightball70

A new version 2 of the patch "NUC HDMI port issues" has been posted: [V2] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues

BROKEN due to Kodi bug: I've uploaded #0614b: libreelec-generic.x86_64-9.0-milhouse-20180614232731-#0614b-g83c436f.

This build uses the V2 patch [V2] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. - Patchwork instead of linux (Generic): drm/i915/glk: GLK HDMI workarounds (i915.glkhdmi=2) · LibreELEC/LibreELEC.tv@88b6533 · GitHub (the i915.glkhdmi=2 parameter is no longer required by the V2 patch).

EDIT: Use build #0614c in this post.

Sorry missed the update notification (again).

Quote from laric

I get it to work on my old 1080p plasma but no image on my brand new 4k qled (QE65Q9FN )

Any log or something I should get out of the system as I get ssh acccess but no picture after the uefi boot screen?

Is this with my #0612b build?

We're really not sure why some users (fortunately a very small number) don't get video after the UEFI boot screen. If you're able to connect to the Samba share, navigate to the Logfiles folder and try uploading the latest zip file to dropbox/googledrive/etc. and post the link. Inside are a number of logfiles, hopefully there might be a clue to what is happening. If you have two video outputs have you tried switching the video cable, it wouldn't be the first time an Intel box has started outputting video on one output only to switch it to the other output during boot.

Quote from laric

milhouse Your build gets stuck at this point on my 2400g. (see picture here: Dropbox - 2018-06-11 10.11.09.jpg )

Is this still an issue for you? Googgling around it looks like the messages may be harmless, and the result of a poorly implemented BIOS.

Question #293489 : Questions : Ubuntu

Bug #1553690 “Lenovo Y700-17ISK: ACPI Errors” : Bugs : linux package : Ubuntu

Bug 1556967 – ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)

Check your ACPI BIOS settings, or see if there's a BIOS update available?

New build #0612b, this includes the GLK workaround (enabled with i915.glkhdmi=2

libreelec-generic.x86_64-9.0-milhouse-20180612142953-#0612b-ga0d6cb2.tar

sky42 there may not be much point backporting the GLK workarounds to 4.14.y as it's likely we'll bump to 4.17.y sooner than later - it's almost certain we won't use 4.14.y for LE9 (on Generic, at least).

This is a new Milhouse build based on (what will be #0611): libreelec-generic.x86_64-9.0-milhouse-20180611180557-#0611c-g783ddf0.tar

This build includes all the latest Vega 12/20/M firmware, CONFIG_DRM_AMD_DC_DCN1_0=y change, and the GLK refresh rate workaround. IR timeout improvements should also be working again in this build.

Quote from sky42

I do fear problems with unwilling hardware, as the quote says "check its availability on your hardware before enabling this option" and we dont know all hardware where it is running on. Just a precaution.

Possibly a standard "here be dragons" warning with all new kernel features - I'd hope AMD DC would be able to identify when FBC isn't available in the GPU hardware and try not to use it (which would be the sane thing to do)... only one way to find out!

Quote from sky42

milhouse i am struggeling to rebuild your #0610b with kernel 4.17. That reset.sh applies both patches and after that it becomes tricky. For the live of it i could not figure out how to build it with all the packages updates, which are not in those patches. Probably i need to create a github account. I tried without.

That package problem aside, i try to build just with libreelec.patch and project.patch. The first fail is i need a milhouse.buildcode, but that was easy fixable.

The second one with a clean build

Code

make[3]: Entering directory '/zfs/sky42/libreelec/90/3.42/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/libX11-1.6.5/.x86_64-libreelec-linux-gnu/src/util'
CC       makekeys.o
/zfs/sky42/libreelec/90/3.42/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/libX11-1.6.5/src/util/makekeys.c:31:19: fatal error: X11/X.h: No such file or directory
compilation terminated.
make[3]: *** [Makefile:425: makekeys.o] Error 1
make[3]: Leaving directory '/zfs/sky42/libreelec/90/3.42/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/libX11-1.6.5/.x86_64-libreelec-linux-gnu/src/util'
make[2]: *** [Makefile:1426: ../src/util/makekeys] Error 2
make[2]: Leaving directory '/zfs/sky42/libreelec/90/3.42/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/libX11-1.6.5/.x86_64-libreelec-linux-gnu/src'
make[1]: *** [Makefile:519: all-recursive] Error 1
make[1]: Leaving directory '/zfs/sky42/libreelec/90/3.42/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/libX11-1.6.5/.x86_64-libreelec-linux-gnu'
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 2

Display More

I had the same problem as i first tried your 00_mesa1811_xorg120_combo.txt patch and then failed back to PR2739 to get Mesa 18.1.1.

It was fresh checkt out and nothing else than reset.sh followed by make image was done.

Ah yes... to actually build that repo (rather than just review the patches) you'll need my own custom build system which is mentioned here: Python not building

milhouse.buildcode would be created by my build scripts.

In addition to the patches my build system automatically updates the source tarballs of several packages (kodi, libcec, libnfs, pvr.* etc.) which you are most likely missing.

With my build scripts if you wanted to recreate my build, you'd use "./totalbuild.sh -s x86-next" and that would Generic with the 4.17 kernel (pulling the latest PRs from github, so you're not always guaranteed a successful build!)

The main configuration files are lepull.dat and ipatches.dat, with profiles (ie. x86-next) defined in profiles.dat.

Quote from sky42

milhouse

My kernel config for AMD DC is different than yours

i am not sure about that one and it is off

# CONFIG_DRM_AMD_DC_FBC is not set

and this need to be on

CONFIG_DRM_AMD_DC_DCN1_0=y

Display More

Thanks, I'll enable the CONFIG_DRM_AMD_DC_DCN1_0=y

I enabled Frame Buffer Compression as in theory it should increase the effective memory bandwidth - have you had any problems with it?

Quote from sky42

milhouse

My GLK Bug 105887 patches i use

kernel-4.14.47-GLK-bug-105887-2-workarounds-2018-05-28.patch.txt

kernel-4.16.13-GLK-bug-105887-2-workarounds-2018-05-28.patch.txt that one works also with 4.17

but there seems to be a more final one, but i did not use it so far

Intel GFX - Patchwork

and my xorg server pci_id updates

xorg-server-1.19.6-sync_pci_ids_1.20.0.patch.txt

xorg-server-1.20.0-update_pci_ids.patch.txt

Display More

Thanks!

I've cherry-picked:

Intel GFX - Patchwork

xorg-server-1.20.0-update_pci_ids.patch.txt

Quote from porkchop999

Thanks and working well so far on my NUC7PJYH

Edit: spoke to soon it looks like I have the refresh rate switching issue without the i915.glkhdmi=2 patch

OK I'll see about it adding it in my branch - thanks.

Quote from porkchop999

Thanks to both of you for doing these builds milhouse is the i915.glkhdmi=2 still required in your build ?

No I don't have that patch in my build.

4.17 version of my most recent #0610 build is here: libreelec-generic.x86_64-9.0-milhouse-20180610225938-#0610b-g783ddf0.tar

It is missing the DVB addons, and the improved IR timeout handling (fixed soon, hopefully) but should be functional - it boots on a Skylake i5 NUC and a Revo3700 (ION2/Atom).

Quote from sky42

milhouse

My last test was a full clean build of 9.0-devel df52423 + PR2739 + PR2449 + PR2760. I also testet only + PR2670. My build system is a Ubuntu VM 16.04.4 just to comple LE and i followed the wiki artikel for that. I switched of ccache at the moment with CCACHE_DISABLE=1.

I did cleaup the /storage on my test Haswell NUC D34010WYK with Pulse Eight NUC HDMI-CEC Adapter. The 2nd step would be test my Coffe Lake i3-8100.

It is booting und stuck at the Kodi v18.0 Logo. After a while (minutes not hours) it reboots. Here ist the crashlog kodi_crashlog_20180610100706.log. I have no idea what to do.

Is there a way to get the complete source of your test build from your v18.0 test build thread LibreELEC Testbuilds for x86_64 (Kodi 18.0) for #0609? I would like to checkout your test build source with all the changes from the release post of #0609 and of course for every following one. At the moment i would then apply the 105887 GLK HDMI bug workarouns for kernel 4.14 and try a 2nd one with 4.17 and later firmware for the AMD users. And probably i need to update pci_ids for xorg 1.20.0, because shortly after release there was a update of pci_ids.

Sorry, I didn't get any notifications there had been new posts in this thread.

Yes, looks like Python is crashing.

The complete source of my build is included within the tar file - there's a file called milhouse.build.0610.tar.gz within the tar file, if you extract this and then extract the contents you'll have all my build scripts, and the configuration for the build, plus all the patches. If you extract the contents of the milhouse tar, cd to a "clean" LibreELEC repository, then run <milhouse tar contents>/config/reset.sh it will apply all of my patches to the repository.

Fortunately it sounds like you've now got a working build - I've lost count of the number of clean builds I've had to make over the last week!

I've started looking at a new mainline 4.17 kernel for Generic, with AMD DC support - the branch is here: Comparing LibreELEC:master...milhousevh:linux4170 · LibreELEC/LibreELEC.tv · GitHub - I may pinch some of your commits.

I'll post a link to an initial 4.17 build later, as it would be good to get feedback from AMD GPU users.

Quote from sky42

At the moment it is really looking bad for my LE 9.0 community build. I cant get a baseline. Every build has the same problem: just a kodi logo and after a while reboot or frozen. The OS is working, ssh too, xrandr showing connected displays ... But that is it.

I did build now about 10 different version. Even fresh checkout from git does not work (does not even build without a extra PR).

Do you mean LE master is not booting into Kodi with the 4.14.48 kernel? You will need to build with the sqlite shared PR2760, but with that PR you should have a successful build.

The current LE master should is working on known-good CPUs, (ie. Skylake etc.). It should work on Coffee Lake, and might even work on Gemini Lake. For Ryzen, it should work, but Vega isn't supported until 4.17.y. Like you I have none of this new hardware, so can only guess at what might not be working.

If your builds are making it into Kodi and then crashing, there should be a crash log which might give some clues.

Quote from E000001

Thanks, for your fast reply. My OS is Win10 Pro - 1803. I discovered, that if minimal version is set to smb1 then it is working. But I think It is a security risk.

So when you said "It is impossible to connect to RPi" what you actually meant was "I can't see the RPi when browsing the network", correct?

Network browsing no longer works (and this has been pointed out so many times), as it requires SMB1 which you should not use. Ever. You should not even leave SMB1 enabled in your Windows 10 machine, as SMB1 is a security risk _even when you don't use SMB1_.

Get used to entering the \\ipaddress as donbrew has pointed out.

Quote from E000001

Tried set minimal SMB to all versions and activate authentication, but no results.

Please be _very_ clear about what you have tried, what the problem is, and what clients are involved.

What is your client - is it a Windows PC? What version - is it Windows 10 with the latest 1803 update?

Where did you activate authentication? Activating authentication in the client won't have any effect when accessing the LibreELEC Samba Server, but you may need to activate authentication in the LibreELEC Samba Server if your client (whatever that is, because we don't know) now enforces authentication when accessing shares.

You should leave the SMB versions at default, as min=SMB2 should be supported by all but the oldest clients.