Bug 107441

Created attachment 140912 [details]
dmesg 4.4 only

Dmesg of before/after 3774eb507e7b7df7f9b7d8d867eea330c7146aaa would be nice.

Created attachment 140913 [details]
dmesg 4.4 with 4.15 load after initramfs

Created attachment 140914 [details]
dmesg 4.4 with 4.15 load in initramfs

Created attachment 140915 [details]
Filter script for dmesg to compare drm output

So it's the regression from around 3.2 where disabling active outputs that we fail to takeover, with the insistence by the HW people that we had to avoid using stolen offset==0 in bdw.

commit 011f22eb545a35f972036bb6a245c95c2e7e15a0
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Fri Apr 20 11:59:33 2018 +0200

    drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2
    
    Before this commit the WaSkipStolenMemoryFirstPage workaround code was
    skipping the first 4k by passing 4096 as start of the address range passed
    to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
    reserve the firmware framebuffer so that we can inherit it would always
    fail, as the firmware framebuffer starts at address 0.
    
    Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
    everything >= gen8") says in its commit message: "This is confirmed to fix
    Skylake screen flickering issues (probably caused by the fact that we
    initialized a ring in the first page of stolen, but I didn't 100% confirm
    this theory)."
    
    Which suggests that it is safe to use the first page for a linear
    framebuffer as the firmware is doing (see note below).
    
    This commit always passes 0 as start to drm_mm_init() and works around
    WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
    by insuring the start address passed by to drm_mm_insert_node_in_range()
    is always 4k or more. All entry points to i915_gem_stolen.c go through
    i915_gem_stolen_insert_node_in_range(), so that any newly allocated
    objects such as ring-buffers will not be allocated in the first 4k.
    
    The one exception is i915_gem_object_create_stolen_for_preallocated()
    which directly calls drm_mm_reserve_node() which now will be able to
    use the first 4k.
    
    This fixes the i915 driver no longer being able to inherit the firmware
    framebuffer on gen8+, which fixes the video output changing from the
    vendor logo to a black screen as soon as the i915 driver is loaded
    (on systems without fbcon).
    
    Some notes about the mapping of the BIOS framebuffer:
    
    v1 led to some discussion if the assumption of the intel_display.c code
    that the firmware framebuffer is a linear mapping of the stolen memory
    starting at offset 0 is still correct, because that would mean that the
    GOP does not implement the WaSkipStolenMemoryFirstPage workaround.
    
    To verify this the following code was added at the end of
    i915_gem_object_create_stolen_for_preallocated() :
    
    pr_err("first ggtt entry before bind: 0x%016llx\n",
           readq(dev_priv->ggtt.gsm));
    ret = i915_vma_bind(vma,
                HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE,
                PIN_UPDATE);
    pr_err("i915_vma_bind ret %d\n", ret);
    pr_err("first ggtt entry after bind: 0x%016llx\n",
           readq(dev_priv->ggtt.gsm));
    
    Which prints the mapping of the first page, then does a vma_bind() to
    force update the mapping with our linear view of the framebuffer and
    then prints the mapping of the first page again.
    
    On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints:
    
    [    1.651141] first ggtt entry before bind: 0x0000000078c00001
    [    1.651151] i915_vma_bind ret 0
    [    1.651152] first ggtt entry after bind: 0x0000000078c00083
    
    And "sudo cat /proc/iomem | grep Stolen" gives:
      78c00000-88bfffff : Graphics Stolen Memory
    
    There are no visual changes with this patch (BIOS vendor logo still
    stays in place when we inherit the BIOS framebuffer), so the vma_bind()
    does not impact which memory is being scanned out.
    
    The address of the first ggtt entry matches with the start of stolen
    and the i915_vma_bind call only changes the first gtt entry's flags,
    or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly
    matches what we would expect based on gen8_pte_encode()'s behavior.
    
    So it seems that the GOP indeed does NOT implement the wa and the i915's
    code assuming a linear mapping at the start of stolen for the BIOS fb
    still holds true for gen8+.
    
    I've also tested this on a Cherry Trail based device (a GPD Win)
    with identical results (the flags are 0x1b after the vma_bind
    on CHT, which matches with I915_CACHE_NONE).
    
    Changed in v2: No code changes, extended the commit message with the
    verification that the intel_display.c BIOS framebuffer mapping is still
    correct.
    
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180420095933.16442-1-hdegoede@redhat.com

Which made it into 4.18-rc7, so another dmesg from current is required as it may be a different issue.

So I applied the patch

commit 011f22eb545a35f972036bb6a245c95c2e7e15a0
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Fri Apr 20 11:59:33 2018 +0200

    drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2

on top of my DRM backport and now the dmesg output is again

[    5.912030] [drm:intelfb_create [i915_bpo]] re-using BIOS fb
[    5.912121] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb: 0x00000000

instead of the broken

[    4.244504] [drm:intelfb_create [i915_bpo]] no BIOS fb, allocating a new one
[    4.244538] [drm:intelfb_create [i915_bpo]] allocated fb from stolen memory
[    4.246099] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb: 0x00040000

Is that what you expected?

Oh - and at least two boots had the correct plymouth boot splash images on the U757. Will test my other HW.

(In reply to Jan-Marek Glogowski from comment #9)
> So I applied the patch
> 
> commit 011f22eb545a35f972036bb6a245c95c2e7e15a0
> Author: Hans de Goede <j.w.r.degoede@gmail.com>
> Date:   Fri Apr 20 11:59:33 2018 +0200
> 
>     drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated
> buffers v2
> 
> on top of my DRM backport and now the dmesg output is again
> 
> [    5.912030] [drm:intelfb_create [i915_bpo]] re-using BIOS fb
> [    5.912121] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb:
> 0x00000000
> 
> instead of the broken
> 
> [    4.244504] [drm:intelfb_create [i915_bpo]] no BIOS fb, allocating a new
> one
> [    4.244538] [drm:intelfb_create [i915_bpo]] allocated fb from stolen
> memory
> [    4.246099] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb:
> 0x00040000
> 
> Is that what you expected?

Yes. But I'm worrying about your earlier result with 4.18rc7 as that includes the patch.

(In reply to Chris Wilson from comment #11)
> (In reply to Jan-Marek Glogowski from comment #9)
> > So I applied the patch
> > 
> > commit 011f22eb545a35f972036bb6a245c95c2e7e15a0
> > Author: Hans de Goede <j.w.r.degoede@gmail.com>
> > Date:   Fri Apr 20 11:59:33 2018 +0200
> > 
> >     drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated
> > buffers v2
> > 
> > on top of my DRM backport and now the dmesg output is again
> > 
> > [    5.912030] [drm:intelfb_create [i915_bpo]] re-using BIOS fb
> > [    5.912121] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb:
> > 0x00000000
> > 
> > instead of the broken
> > 
> > [    4.244504] [drm:intelfb_create [i915_bpo]] no BIOS fb, allocating a new
> > one
> > [    4.244538] [drm:intelfb_create [i915_bpo]] allocated fb from stolen
> > memory
> > [    4.246099] [drm:intelfb_create [i915_bpo]] allocated 1366x768 fb:
> > 0x00040000
> > 
> > Is that what you expected?
> 
> Yes. But I'm worrying about your earlier result with 4.18rc7 as that
> includes the patch.

So I've retested the HW. The patch works on the Fujitsu U757 with the Ubuntu 12.04 + kernel 4.4 + my 4.15 DRM backport.

I'm not sure what's happening for 4.18 on the Acer n4640g HW.

* It's working when booting with i915.ko in the initramfs
* The monitor is blank, if booting with i915.ko just in the root fs

$ grep "re-using BIOS fb" dmesg-4.18*
dmesg-4.18_initramfs:[    2.042702] [drm:intelfb_create [i915]] re-using BIOS fb
dmesg-4.18_rootfs:   [   18.468958] [drm:intelfb_create [i915]] re-using BIOS fb

To be more precise, the "blank" screen is a monitor with backlight switched on. I can switch to the VT with a plymouth running with the correct image, which I didn't check earlier.

Now all of this might be a systemd or plymouth problem; but still in the initramfs case I have a splash on the correct VT from the beginning.

Created attachment 140918 [details]
dmesg 4.18 with i915.ko in initramfs

Created attachment 140919 [details]
dmesg 4.18 with i915.ko just in the root fs

And to be more precise I also see the boot splash in the rootfs case until the i915.ko is loaded (I guess), which is really late on the hardware. It's just a "Celeron® G3900T" and a HDD.

Reporter, can you still try using latest https://cgit.freedesktop.org/drm-tip and send dmesg with debugs?

Created attachment 141064 [details]
dmesg 4.18+drmtip with i915.ko in initramfs

commit 3010d040760de7eb87c6eb54985ba6220447bbba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 13 13:59:02 2018 +0100

    drm-tip: 2018y-08m-13d-12h-57m-37s UTC integration manifest

Created attachment 141065 [details]
dmesg 4.18+drmtip with i915.ko just in the root fs

$ grep "re-using BIOS fb" *tip*
dmesg-4.18-drmtip_initramfs:[    1.727499] [drm:intelfb_create [i915]] re-using BIOS fb
dmesg-4.18-drmtip_rootfs:[   19.842296] [drm:intelfb_create [i915]] re-using BIOS fb

1. i915.ko in initramfs: works as expected (splash animation from boot)

2. i915.ko loaded late from rootfs: I still just see the splash image for a second and then have a black screen. If I switch the VT manually, I can switch to the correct splash image, which is no longer broken.

Plymouth is loaded before i915 in the rootfs case?

Jan-Marek, can you answer to Maarten's question.

Created attachment 141167 [details]
initramfs-tools hook to remove i915.ko module

(In reply to Maarten Lankhorst from comment #19)
> Plymouth is loaded before i915 in the rootfs case?

There was a public holiday here in Bavaria / Germany, so sorry for the delay…

Yup. On Ubuntu / Debian plymouthd is started via an initramfs-tools script (/usr/share/initramfs-tools/scripts/init-premount/plymouth), so you get a nice splash screen for cryptsetup.

AFAIK that splash doesn't work without a DRM device, so if I kick the i915.ko module from the initramfs, I get no splash but still plymouthd is started (hook script goes to /etc/initramfs-tools/hooks/)

I updated my system, and now I always end up with black screen (still Ubuntu 16.04 with a kernel 4.18).

In the "early case" I get the splash until some point. Then I can manually change the VT from 1 => 2 => 1 and it re-appears.

In the late case, now all VTs are black.

I both cases 'plymouth --quit' quits plymouthd and restores the VTs, which would normally happen anyway, as I disabled that services to see the splash after boot.

All this might be a user space problem. Probably some timing changed due to the new packages. Normally a systemd service would stop plymouth, which I changed to /bin/true for the testing.

If you have any other idea for me to test, feel free to ask me.

plymouth should probably be started after i915 is, so that would explain. :)

I'm leaning more towards thinking of a bug with plymouth than i915.

Reporter, this seems to be not a i915 bug from the above investigation. Can I close this bug?

This issue is not related to i915 driver. Closing as NOTOURBUG.