[Bug 107441] New: Black or broken VT when loading i915.ko "late"

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107441

            Bug ID: 107441
           Summary: Black or broken VT when loading i915.ko "late"
           Product: DRI
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: glogow at fbihome.de
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 140911
  --> https://bugs.freedesktop.org/attachment.cgi?id=140911&action=edit
Broken LiMux plymouth bootsplash logo

My hardware is a Skylake notebook (Fujitsu U757) and desktop (Acer Veriton
n4640g).
I'm on Ubuntu 12.04 with 14.04 HWE kernel, but this problem also happens with
current 4.18rc7.
Both HWs have two monitors connected via DisplayPort, but it also happens with
a single monitor.

When loading the i915.ko driver late in the boot process (after initramfs),
when replacing the vesafb with the inteldrmfb, plymouth boot splash breaks in
various ways. Sometimes the image offset is wrong (see attached image),
sometimes the stride is wrong and sometimes the the screen is black.
If I manually stop and start the plymouth daemon, everything is fine.
The VT is correct, if pressing ESC and pressing ESC again restores the broken
VT.

For me it looks like the main difference between a broken and working kernel is
the changed framebuffer allocation as a result of:

commit 3774eb507e7b7df7f9b7d8d867eea330c7146aaa
Author: Paulo Zanoni <paulo.r.zanoni at intel.com>
Date:   Mon Aug 10 14:57:32 2015 -0300

    drm/i915: fix stolen bios_reserved checks

as this forces the framebuffer to be newly allocated instead of claiming the
stolen memory from the VESA BIOS, which is in a reserved area.

After testing various kernels and drivers and checking DRM debug output, I
realized it's probably a timing problem:

* If I put the driver into the initramfs, it works correctly
* If I remove the driver from the initramfs, it always breaks

It can be broken in various ways:
* Black screen
* Shifted image due to wrong offset, like in the attached photo
* Shifted image due to a wrong width / stride, which is just a mess

I tested this behavior with:
* Ubuntu 12.04 + linux-image-4.4.0-130-generic (4.4.0-130.156~14.04.1) + my
4.15 DRM backport
* Ubuntu 18.04 + linux-image-4.15.0-29-generic (4.15.0-29.31)
* Ubuntu 18.04 + linux-image-4.16.18-041618-generic
(4.16.18-041618.201806252030)
* Ubuntu 18.04 + linux-image-4.17.11-041711-generic
(4.17.11-041711.201807280505)
* Ubuntu 18.04 + linux-image-4.18.0-041800rc7-generic
(4.18.0-041800rc7.201807292230)

Now I don't know if this is really a kernel or a plymouth problem, because
eventually the i915 driver in the initramfs is loaded before plymouth.

------ Background info

I'm trying to backport DRM 4.15 to 4.4 (AKA Ubuntu Bionic 18.04 => Ubuntu
Trusty 12.04 + Xenial HWE).
And I'm mainly interested in the i915 driver and the DisplayPort fixes, as I
know Ubuntu 18.04 is able to bring up the 2nd monitor on the Acer HW, which
fails with 4.4 kernel.

I also hope the 4.15 backport fixes some power management wakeup problem, where
the monitor doesn't wakes up after lunch. Most times the workaround seems to be
to power-cycle the monitor, but sometimes people also got PIPE underrun errors,
which need a reboot. Since this is not really reproducible, I don't know how to
debug this, as it just happens with the users already running the HW.

I also tried the code from
https://launchpad.net/~canonical-hwe-team/+archive/ubuntu/ppa, which contains a
port of 4.9 => 4.4.
This works correctly for this problem (it still steals the memory from the
vesafb), but doesn't contain the DisplayPort fixes I'm actually interested in.
The fixes allows my HW to use the 2nd DP, which works with 4.15 (and which got
broken again in 4.17 AFAIK, but that's an other bug I'll open).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180801/db30859e/attachment.html>