LE 8.9.007 and newer won't boot on Kaby Lake Celeron 3965U

1st Official Post

    Cannot boot LE 8.9.007+ on Celeron 3965U mini pc system - it resets (boot cycles) a few moments after Libreelec logo is displayed, and build number appears on the top left of the screen.

    I've tried both live and installed variants. Latest Milhouse build exhibits the same behaviour.

    8.9.006 and earlier alpha builds, including latest stable 8.2.5, boot fine.

    dmesg of successful 8.9.006 boot: https://paste.ee/r/9tqbv/0

    Looks like it's not LibreElec's fauit. From what I see in github changelog, 8.9.007 moved to 4.19 kernel, and it is my problem. I've just tried ubuntu 18.10 with 4.19, and it won't boot as well: during Gnome Manager startup I see a similar momentary screen distortion and then it hangs. Duh.

    Edited 2 times, last by allixx: fixed incomplete dmesg dump, tried other distro (December 7, 2018 at 4:07 PM).

    It's a chinese mini pc, so iGFX is all there is.

    They slapped in a development/debug AMIBIOS with lots of options, and I explored all gfx&other semi-relevant ones but got no luck. I've also played with i915 module kernel boot options the people on the internet used to solve their Kaby Lake notebooks gfx-related hangs, but as you guess nothing helped.

    Meanwhile I've tried a new Milhouse build with 4.19.7 and saw no improvement.

    1) If removing quiet from and adding progress to the live mode APPEND line, can you see how far it boots?

    2) Are there any changes in behaviour it you use the latest Milhouse 4.20-rc build?

    Quote from mglae

    1) If removing quiet from and adding progress to the live mode APPEND line, can you see how far it boots?

    Last line before reset is "Starting to configure Xorg server for i915".

    Quote from mglae

    2) Are there any changes in behaviour it you use the latest Milhouse 4.20-rc build?

    Didn't know there was one. Tried latest snapshot of "build/next/Generic", got the same result.

    I managed to capture dmesg outputs of successful and not successful (resetting) runs with progress drm.debug=0xe debug ignore_loglevel options by removing the usb boot disk in timely fashion :)

    Success (kernel 4.18.11, alpha 006): https://paste.ee/r/sj89d/0

    Failure (kernel 4.19.4, alpha 009): https://paste.ee/r/grmht/0

    Failure (kernel 4.20, next LibreELEC-Generic.x86_64-9.0-Milhouse-20181129005231-#1128x-g63fb241.tar): https://paste.ee/r/ocdrz/0

    I compared the good (4.18.11) and bad (4.19.4) logs line by line found the following difference:

    good:


    bad:

    present in good, missing in bad:

    Code
    [drm:skylake_get_initial_plane_config] pipe A/plane 1A with fb: size=1920x1080@32, offset=0, pitch 7680, size 0x7e9000
[drm:i915_gem_object_create_stolen_for_preallocated] creating preallocated stolen object: stolen_offset=0x000000000000000
0, gtt_offset=0x0000000000000000, size=0x00000000007e9000
[drm:intel_alloc_initial_plane_obj.isra.131] initial plane fb obj (____ptrval____)
[drm:intel_set_plane_visible] pipe A active planes 0x1

    The difference is most likely due to the fact that there was a framebufffer console in one case, and 80x25 in another. So the only real difference is i915 module version, 1.6.0 20180514 vs 1.6.0 20180719.

    Maybe someone with i915 driver understanding can take a look and notice any clues?

    Edited 4 times, last by allixx: replaced success dmesg dump by more complete log; added log comparision (December 9, 2018 at 5:04 PM).

    So I played with bisecting the kernel and found out that bug appears after this commit:

    kernel/git/stable/linux.git - Linux kernel stable tree

    The merge is not small and I'm having a hard time isolating the patch that caused the issue.

    Meanwhile I found out that supplying intel_idle.max_cstate=1 as kernel boot option get rids of the bug.

    EDIT: After some more tinkering I found out that setting Package C State Limit BIOS option to C7S instead of Auto solves the problem, and intel_idle.max_cstate kernel option is not required anymore.

    I guess the thread kind of auto solved itself.

    Edited once, last by allixx (December 13, 2018 at 6:46 PM).