Bug 108264

Summary:

[bisected] Console garbled on MacBookPro's

Product:

DRI

Reporter:

Ronald <ronald>

Component:

DRM/Intel

Assignee:

Imre Deak <imre.deak>

Status:

CLOSED FIXED

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

normal

Priority:

high

CC:

daniel, imre.deak, intel-gfx-bugs, jwrdegoede, lakshminarayana.vudum, ville.syrjala

Version:

DRI git

Keywords:

regression

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

Triaged, ReadyForDev

i915 platform:

SKL

i915 features:

display/Other

Attachments:

Description	Flags
dmesg output from booting drm-tip with drm.debug=0x1e	none
Screenshot of the glitch	none

Description Ronald 2018-10-07 09:19:24 UTC

Created attachment 141927 [details]
dmesg output from booting drm-tip with drm.debug=0x1e

Starting with kernel 4.18-rc1 the console is garbled (see the screenshot in the first comment of https://github.com/Dunedan/mbp-2016-linux/issues/76) on MacBookPro 13,* and 14,* (when using the iGPU on those with dual GPU's). This happens on boot, after grub and the basic kernel loading messages. The graphical parts (plymouth, gdm, X11/Wayland) are not affected, however.

I bisected the problem down to commit 011f22eb545a35f972036bb6a245c95c2e7e15a0 (drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2) - reverting that has been verified to fix the issue on two different machines. I also verified the problem still occurs at current drm-tip (though that has an additional issue where the screen flickers).

The list of graphics cards of the affected machines is:
Iris Graphics 540
Iris Graphics 550
Intel HD Graphics 530
Iris Plus Graphics 640
Iris Plus Graphics 650
Intel HD Graphics 630

Note that this seems similar to https://bugs.freedesktop.org/show_bug.cgi?id=107951, but the garbling here is full screen and starts at boot.

Comment 1 Lakshmi 2018-10-09 13:56:06 UTC

Created attachment 141959 [details]
Screenshot of the glitch

screenshot of the glitch is taken from github and attached here.

Comment 2 Imre Deak 2018-10-09 14:15:41 UTC

Looks really like an FB corruption problem reported by Mika Westerberg. He bisected it to

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

Later Ville spotted in dmesg that it's caused by an incorrect assumption by the initial FB allocation code that an active FB during booting is always in stolen memory. In this case it's not and as a result the driver won't reserve the actual backing pages which will be later corrupted by whatever happens to allocate these pages.

Solution is to throw away the active FB in this case and allocate a new one. I'm planning to follow up with a patch for that.

Comment 3 Imre Deak 2018-10-09 14:23:34 UTC

(In reply to Imre Deak from comment #2)
> Looks really like an FB corruption problem reported by Mika Westerberg. He
> bisected it to
> 
> 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
> 
> Later Ville spotted in dmesg that it's caused by an incorrect assumption by
> the initial FB allocation code that an active FB during booting is always in
> stolen memory. In this case it's not and as a result the driver won't
> reserve the actual backing pages which will be later corrupted by whatever
> happens to allocate these pages.
> 
> Solution is to throw away the active FB in this case and allocate a new one.
> I'm planning to follow up with a patch for that.

ronald, oops, sorry didn't notice that you already bisected the same commit. So this is definitely the same problem then.

Comment 4 Hans de Goede 2018-10-09 14:27:48 UTC

Imre, thanks, given your comment I will let you deal with this.

Comment 5 Imre Deak 2018-10-17 10:51:15 UTC

Fixed in drm-tip:

commit 914a4fd8cd28016038ce749a818a836124a8d270
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Oct 16 19:00:11 2018 +0300

    drm/i915/gen9+: Fix initial readout for Y tiled framebuffers

Comment 6 Lakshmi 2018-10-23 13:19:25 UTC

Ronald, can you please verify this issue with latest drm-tip?https://cgit.freedesktop.org/drm-tip

Comment 7 Ronald 2018-10-23 22:20:35 UTC

(In reply to Lakshmi from comment #6)
> Ronald, can you please verify this issue with latest
> drm-tip?https://cgit.freedesktop.org/drm-tip
Yes, I can confirm it's fixed in drm-tip (at commit 166bc98d7b7700594).

Thanks for everybody's work here!

Comment 8 Lakshmi 2018-10-24 06:55:19 UTC

Thanks for the feedback. Closing this bug as Resolved/fixed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.