In SteamOS, GRUB is patched to leave the contents of the EFI framebuffer alone when booting the kernel, and the kernel is passed fbcon=vc:2-6 to leave VT1 alone, as to guarantee a smooth transition until X is started later. This works fine for drivers that don't attempt to mess with efifb, but on the Intel driver this results in screen flickering with colorful corruption near the top of the framebuffer, before the framebuffer contents settle to the correct picture. I believe the Intel folks already have a solid repro scenario for this, but I'm happy to provide more data if others are interested.
I have some patches to the Intel driver that may help. My code is available from the inherit-bios branch of my git tree on fdo: git://people.freedesktop.org/~jbarnes/linux. Would it be possible for you to try that?
I tested the inherit-bios branch on my gentoo based ivb-gt2 system. I've uploaded videos of steamos, gentoo with 3.13 from linus tree, and of the inherit-bios kernel. The problem is reduced in the inherit-bios branch, but not fixed entirely. You can get the videos from my fdo account: http://people.freedesktop.org/~dbaker/graphics_corpution_i915/
Hm, in the videos, I see some text messages display in both the stock and inherit-bios branches, but no corruption. The corruption is clearly visible in the steamos video though. So are you down to trying to get rid of the text messages?
I also still seem to see some corruption near the top of the screen in the gentoo_inherit-bios.mp4, but the gentoo environment uses an unpatched GRUB and I'm not sure what initial mode the firmware is setting, so it's possible that transition also involves a modeswitch. If possible I would check the patches with a SteamOS GRUB/kernel and a Brix box, since it has a known good EFI firmware.
Jesse: Unfortunately I can't get rid of the text from my boot the same way that steamos does, as I have an encrypted home partition and would have no way to decrypt it without virtual console 1. I have uploaded pngs from the gentoo videos at around :03 which show the corruption (http://people.freedesktop.org/~dbaker/graphics_corpution_i915/). It is much harder to see on my system since it boots much faster than the brix box does, this may be becasue I don't use an initrd. I attempted to apply the top 10 patches from jesse's branch to the steamos source, but they don't apply cleanly and I'm a terrible C programmer on a good day, so I'm not sure what more I'll be able to do without sources.
Did you try with i915.fastboot=1? Also, I'd be interested in getting logs from this boot with drm.debug=0x6. Thanks.
steamos, or the gentoo system?
Gentoo is fine since you can see the corruption there.
Created attachment 123701 [details] steamos dmesg with drm.debug=0x6
looks like the top of the log got cut off, and did you boot with i915.fastboot=1? Can you post a log from the gentoo system with fastboot=1 including the early parts? Thanks.
Created attachment 123811 [details] dmesg from gentoo 3.13
Created attachment 123821 [details] dmesg from gento with 3.13-r4-inherit-bios
(In reply to Jesse Barnes from comment #10) > looks like the top of the log got cut off, and did you boot with > i915.fastboot=1? Can you post a log from the gentoo system with fastboot=1 > including the early parts? Thanks. The kernel in steamos does not support i915.fastboot, setting it results in i915 not being loaded.
Ok I just updated the inherit-bios branch with code that ought to fix this. I tested it here and it worked, but haven't yet tested on a BRIX box. I should be able to do that next week when I get home, but in the meantime, can you try it out? Thanks, Jesse
On my Ivybgride it has fixed the issue. My brix box has only steamos installed on it at the moment, but I'll try to fire up ubunut today or tomorrow and check there too.
I can try this out as well, but your git repository doesn't appear to be served over HTTP and this page seems to be down: http://cgit.freedesktop.org/~jbarnes/linux/ If you attach me a patch I can apply on top of mainline I can let you know how it works on the Brix machines running SteamOS.
The latest patchset is in this thread (look for the series with the v10 patch): http://lists.freedesktop.org/archives/intel-gfx/2014-February/039775.html It applied cleanly last week against the drm-intel-nightly branch. The git repo should be available through anonymous git using git:// if you want to use that instead.
Looks like this is far from applying cleanly on our 3.10 kernel, as intel_fbdev.c doesn't even exist there. For now we'll just live with this problem until someone becomes annoyed enough to do the rebase themselves. Thanks for looking into this, I saved the patch series for future use.
I'll install the latest SteamOS on my system in the meantime and see how hard a backport would be (the file used to be called intel_fb.c, but there are quite a few changes to deal with beyond that).
If the goal is to simply fix the corruption (and potential GPU hangs), we can just disable all outputs at the beginning of i915.ko. That used to be a trivial operation...
Would that still result in a seamless transition between the bootloader and the driver, with no flickering of any kind?
No, it hides the corruption by turning the outputs for ~.3s between loading of i915.ko and enabling fbcon. It is what the code used to do... fastboot aims to eliminate all modesets between the BIOS and fbcon, thereby completely eliminate the flicker and corruption. It just has a few hacks remaining as the core modesetting code is not quite intelligent enough yet to handle the seamless transition.
Jesse, where are we with this bug?
I'm not sure if anyone has tried to reproduce this now that the fbcon takeover code has landed, it may no longer be an issue. Pierre-Loup, any updates?
Can you point me at the release I should be testing and any non-default parameters I should be passing at boot in order to try and reproduce the problem with the fbcon takeover code in effect?
Just the current drm-intel-nightly tree from git://anongit.freedesktop.org/drm-intel with the default parameters ought to be enough for testing. You can also try passing the i915.fastboot=1 parameter on the boot line to see if that makes any difference, but I'd try without it first.
Presumed fixed upstream, closing. Please reopen if the problem persists with current kernels.