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.
Created attachment 141959 [details] Screenshot of the glitch screenshot of the glitch is taken from github and attached here.
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.
(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.
Imre, thanks, given your comment I will let you deal with this.
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
Ronald, can you please verify this issue with latest drm-tip?https://cgit.freedesktop.org/drm-tip
(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!
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.