kernel compiled static, booting via uefi stub, 3.13.x. Tested both kernel.org sources and hardned sources (ignore the harded menu option). https://www.youtube.com/watch?v=yxDyvyJTrXs Will attach dmesg with 'drm.debug=0xe' soon. Let me know if there is other testing you wish to be done.
Is this a regression, i.e. did this use to work with some previous kernel version? Which? Please prevent i915 from loading, to see if there's corruption before the driver is loaded.
Last kernel it worked with was 3.12.8. Do you have a way to prevent the loading of a static (built in) kernel module (like i915=disable or something)?
(In reply to comment #2) > Last kernel it worked with was 3.12.8. > > Do you have a way to prevent the loading of a static (built in) kernel > module (like i915=disable or something)? Hmm, I'm not aware of any tricks to that effect. Please disable it in your config. Also might be worth trying as a module.
i915.modeset=0 will do the trick here.
rebooted with i915.modeset=0 issue is with kms I guess (no corruption with i915.modeset=0)
Still occurs in 3.13.6
Created attachment 95898 [details] here's the dmesg with drm.debug=0xe
Still fails with the same screen corruption on 3.13.7. Anything else needed from me?
tested with 3.14-rc8 and the fail was even worse. I wasn't able to get dmesg. I was able to record and freeze the frame right before switchover from efi to drm. From https://www.youtube.com/watch?v=HRuIAm55eAA (slowed down 8x so no sound, but meh). [drm] Initialized drm 1.1.0 20060810 [drm] Memory usable by graphics device = 2048M fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver all of this seems normal (3.12.8 gives me the same). I slowed down the old video (3.13.5) and here's what I have. [drm] Initialized drm 1.1.0 20060810 [drm] Memory usable by graphics device = 2048M [drm] Supports vblank timestamp caching Rev 2 (21.10.2013) [drm] Driver supports precise vblank timestamp query vgaarb: device chagne decodes: PCI0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem only thing all of this matches 3.12.8 as well, so I don't know where to go, the only thing I can think of is this, but it looks like it's caught in the dmesg I posted earlier. [ 1.270833] [drm] Wrong MCH_SSKPD value: 0x16040307 [ 1.270839] [drm] This can cause pipe underruns and display issues. [ 1.270842] [drm] Please upgrade your BIOS to fix this.
This is marked as a regression. Do we have the bisected bad commit somewhere? If not can you please bisect where exactly this regression was introduced. Also vt-d seems to be enabled. Retesting with latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel is highly advised. With just fixed some rather serious vt-d fallout that resulted in funky display like this one here.
If I can get a patchset or kernel tree to test from that'd work. Are you talking about this commit for the vt-d fix? http://cgit.freedesktop.org/drm-intel/commit/?id=0f4706d2740f2a221cd502922b22e522009041d9
(In reply to comment #11) > If I can get a patchset or kernel tree to test from that'd work. > > Are you talking about this commit for the vt-d fix? > > http://cgit.freedesktop.org/drm-intel/commit/ > ?id=0f4706d2740f2a221cd502922b22e522009041d9 Yeah. If that doesn't help and it's not fixed in nightly we really need the bisect.
This commit is not the fix (at least for this issue). 3.14-rc8 already had the dmar fix and I still had the same type of issue (different type of corruption)
Ok, then I think we need the bisect result to make progress here.
I can work on doing that. is there a way to restrict bisecting to drivers/gpu/drm/i915 ?
Not recommended, could be anywhere. And it's not that much more work to bisect everything than just drm/i915 due to the logarithmic complexity of bisect.
I didn't enable a kconfig option the drm legacy thing I think...
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.