[Solved] LE alpha x86_64-8.90.003: Long boot times + Error starting Xorg

1st Official Post

    Good morning!

    I realised longer boot times since i used Milhouse Builds for my LE device. Its a pretty old Core2 Notebook which is doing a good job for media streaming as a mobile LE device in my house.

    As it is also my test device i installed the newest LE alpha and switched back to 8.2.5.

    LE alpha takes long boot times and shows Xorg error, 8.2.5 boots faster ans shows no visible error.

    Here are the log:

    alpha

    http://ix.io/1jxs

    8.2.5

    http://ix.io/1jxj

    Hope to help making LE more compatible with older hardware.

    Anything else you need?

    Edited once, last by Commerzpunk (August 12, 2018 at 11:53 AM).

    • Official Post

    8.2.5: 20 second boot time

    8.90.003: 1 minute 15 second boot time.

    However, about a minute is lost here.

    Code
    08:39:47.473 T:139926508754688  NOTICE:         m_streamTypes     : No passthrough capabilities
08:40:46.229 T:139926527142016  NOTICE: Checking resolution 16
08:40:46.328 T:139926527142016  NOTICE: Using visual 0x20
08:40:46.353 T:139926527142016 WARNING: Failed to get an OpenGL context supporting core profile 3.2,                               using legacy mode with reduced feature set

    Can you post logfile from 8.90.003 with debug set as explained in my signature.

    As i said in my initial post it is pretty old. Beside that is always was a nice option to play movies in the garden or at any place in my house.

    It is a Intel Core2 Duo T7100 CPU on 965 GM Express Chipset which featues a GMA x3100 Graphics Card.

    Dont laugh at me.

    The strange thing is that there isn't any obvious change in #0801 [2017] which relates to the Intel GPU driver as this seems to be where this issue is occurring. There were some kernel firmware changes in #0801 [2017] but these mostly relate to networking hardware (WiFi and ethernet).

    Quote from Commerzpunk

    Starting with LibreELEC-Generic.x86_64-9.0-Milhouse-20170801215819-#0801-geb93713.tar - should be the first build as i figure out.

    The log you posted is for #0801 [2018], but the tar link you have given is for 2017, so I don't really know what build you are saying is the first with the problem.

    Can you confirm which build is the *FIRST* build with the long delay, and post the log from that long-delay build and also log when booting the build immediately before it.

    Sorry for the confusion.

    Its not visible in the LibreELEC GUI which exact build i am choosing. I just went down the list to the very first entry which i thought was the first #0801 build. The file name i postet was manually chosen from your website, so forget it.

    To clarify: i did not try many builds and identified a specific one that causes the issue, i just wanted to start from the very first.

    Now i simply try the other one which is named #0801 - lets see.

    I am sorry, there is a bug in the update channel > availible versions inside LibreELEC.

    There are two entrys in the list which are both named #0801. One is the very first entry, one is pretty new.

    No matter which one i choose, it always downloads this one: "LibreELEC-Generic.x86_64-9.0-Milhouse-20180801210307-#0801-gd455e47.tar".

    Now i try Build #0811 from 2017, this should be the last oldes one availible because the 2018 build are at #0810.

    Can you use the links from the Kodi website to avoid confusion? LibreELEC Testbuilds for x86_64 (Kodi 18.0)

    Only 12 months of builds will remain online, so #0801 [2017] is the oldest currently available (#0731 [2017] is no longer available).

    The update channel should download the correct build if you choose #0801 [2017] or #0801 [2018], but to be honest that's a secondary issue so if it's causing you a problem then download the tar files directly from the web site.

    Sorry i cant (for today) i am just a user, not a linux expert.

    I am able to choose the entrys from the GUI and try them. I have no idea what tar files are and what to use them for.

    Anyway, i made some progress:

    20170811210530 #0811

    20171001210517 #1001

    20171220214318 #1220

    All these are working fine, quick boot, no Xorg errors.

    Sadly i cant post Logs because there is an error when choosing that option.

    All these are working so far.

    I keep on trying and hope to catch the right one. Getting tiered, but i want to find that build now.

    The next builds will update this post.

    There you go:

    fine 20180101210307 #0101 - http://ix.io/1k1s

    fine 20180321212329 #0321 - http://ix.io/1k1w

    fine 20180427210259 #0427 - http://ix.io/1k1x

    fine 20180520210312 #0520 - http://ix.io/1k1c

    fine 20180601210455 #0601 - http://ix.io/1k1h

    fine 20180615210304 #0615 - http://ix.io/1k1q

    slow 20180616225535 #0616 - http://ix.io/1k1v

    slow 20180617210312 #0617 - http://ix.io/1k1s

    slow 20180618221145 #0618 - http://ix.io/1k1n

    slow 20180622210302 #0622 - http://ix.io/1k1e

    Hope this helps, let me know if i can do anything else.


    .

    Edited 2 times, last by Commerzpunk (August 12, 2018 at 11:24 PM).

    What is odd is that all of your logs - including 8.2.5 - are showing a major problem with your GPU:

    With #0616 we switched from 4.14.y to 4.17.y, which presumably introduced a workaround for the bug or new behaviour that manifests as a delay during boot.

    There is a bug open for "vblank wait timed out on crtc":

    93782 – [i9xx TV][BISECT] vblank wait timeout on crtc

    Unfortunately it remains unresolved after 2 years, and is no longer a priority fix due to the age of the hardware. :(

    You could try adding the following to the LibreELEC kernel command line:

    Code
    video=SVIDEO-1:d

    You'll need to edit /flash/extlinux.conf so that it looks like:

    Code
    DEFAULT linux
PROMPT 0

LABEL linux
 KERNEL /KERNEL
 APPEND boot=LABEL=System disk=LABEL=Storage  quiet video=SVIDEO-1:d

    But if that doesn't fix it, then I wouldn't hold my breath for a fix, and buying new hardware might be the best option (I'll leave it to you to decide whether Intel deserve more of your hard earned cash).