Created attachment 126984 [details]
Xorg.log

(In reply to Luis Botello from comment #1)
> Created attachment 126984 [details]
> Xorg.log

Luis, can you bisect?

Also please use the -intel driver.

There are several issues coming from this (not sure whether all come from same commit, but at least they're caused by the commits surrounding the indicated kernel commit):
* Desktop flickers so badly that it makes the device unusable.  At first the screen may look OK, but after gfx has been used for a while, e.g. by running glxgears, it goes black (and shows the real desktop only e.g. while switching to virtual terminal and back)
* Lightsmark 2008 benchmark colors are wrong in some scenes
* Most SynMark tests are rendered wrong: screeen is divided to (approximately) 128 pixel high stripes which have different offsets

These issues happens *only on BYT*, BDW/BSW/SKL/HSW/SNB are not affected.

Triggering the issues requires *both*:
* kernel from this commit (18th August) or later, and
* modesetting driver or recent Intel DDX.

Issues happen with:
* Latest git version of modesetting built on Ubuntu 16.04 environment
* Modesetting version from Ubuntu 16.04 repos
* "Recent" Intel DDX built on Ubuntu 16.04 environment

However, issue isn't triggered when using older Intel DDX from Ubuntu 16.04:
  http://packages.ubuntu.com/xenial-updates/xserver-xorg-video-intel

(Ubuntu uses version 2.99.917+git20160325 with following patches applied:
- revert-dpms-fix.patch
- preserve-mouse-cursor-after-vt-switch.patch
- add-more-kbl-pciids.diff
- remove-invalid-kbl-pciids.diff
)

I tried bisecting with our pre-built binaries, whether there was some change in Intel DDX that would trigger this but results are inconclusive because we had build environment switch:
  1. Intel DDX built on Gentoo against dependencies pulled from X repositories of that same time (22nd July) doesn't trigger the issue with new kernel (on Ubuntu where the builds are tested)
  2. But same Intel DDX commit built against Ubuntu 16.04 does trigger the issue
  3. However, X server / modesetting built in same environment as 1), does also trigger the issue, so the second trigger (besides kernel) doesn't seem to be just the build environment for Intel DDX

-> IMHO makes more sense to look into kernel.


Luis, can the indicated patch be reverted from latest kernel and if yes, does that fix all the issues?

Highest+Blocker as regression.

(In reply to Eero Tamminen from comment #4)

> (Ubuntu uses version 2.99.917+git20160325 with following patches applied:
> - revert-dpms-fix.patch
> - preserve-mouse-cursor-after-vt-switch.patch
> - add-more-kbl-pciids.diff
> - remove-invalid-kbl-pciids.diff

Hi Eero,
Could you provide a link to the different patches or attach them to this bug if you have them?
Thanks.

(In reply to yann from comment #2)
> Luis, can you bisect?

Bisect what (i.e. why this is marked "bisect_pending")?

First comment already gives the bisected kernel commit.


(In reply to cprigent from comment #6)
> Could you provide a link to the different patches or attach them to this bug
> if you have them?

You can get them either from the diff.gz file on the indicated package page:

(In reply to Eero Tamminen from comment #4)
> However, issue isn't triggered when using older Intel DDX from Ubuntu 16.04:
>   http://packages.ubuntu.com/xenial-updates/xserver-xorg-video-intel

Or doing "apt-get source xserver-xorg-video-intel" on the corresponding distro and checking debian/patches/ dir.

Of the Ubuntu patches, I think the only one that might have some relevance is revert-dpms-fix.patch, which is revert of commit 7d9a74622e5a936e4860fcef8358619bf59adae8.

Mouse cursor patch says following:
---------------
Prevent loss of mouse cursor after VT-switch
The mouse cursor becomes invisible after a VT-switch.
This is commonly seen on systems with light-locker that
switch to the login screen when locking.

This patch pulls from 4 upstream commits:
- 00a3adaf43640b9aaa84b8cb98c1f2f227686689
- 52c9d7ca2467bc273a8ef3c61c1b690ac56caa74
- ebc5e9c3b2241be69bee7b96bd63ef00dacf816c
- f1c757e4518f6835bbff6c940269a5c6be75f202
rigin: upstream, https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=00a3adaf43640b9aaa84b8cb98c1f2f227686689
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94677
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604
--------------

However, I don't think Intel DDX is that relevant for this because the issue can be reproduced also with modesetting driver.


Chris, have you been able to reproduce the issue?

There are (principally) two causes of flickering, either the kernel misprogrammed the mode config (e.g. watermarks) or the frame is being shown before it is ready. The former is less widely reported for byt/vga, but there is definitely a known bug in mesa/DRI3 that causes mesa to render into a buffer that is still on the scanout. However, flicker *after* synmark exits suggests that is a modesetting (kernel) issue - unless there happens to be a GL compositor involved.

The flickering starts as soon as the desktop launches, and almost every screen
update causes the screen to go black. After a short while the screen remains
black and doesn't show anything.

I tried reverting the previously mentioned commit 2efb813 from the latest
drm-intel-nightly and it fixed the flickering issue on BYT.

The flags passed to i915_gem_object_ggtt_pin in
i915_gem_object_pin_to_display_plane changed from PIN_MAPPABLE to
(PIN_MAPPABLE | PIN_NONBLOCK), which seems to have caused the problem.
Changing the flags back to PIN_MAPPABLE also fixed the flickering.

Chris, can you revert this change or fix the issue on BYT?

Chris, what about this issue, can you reproduce it?

(In reply to Eero Tamminen from comment #4)
> * Most SynMark tests are rendered wrong: screeen is divided to
> (approximately) 128 pixel high stripes which have different offsets

This particular issue doesn't happen on BYT with recent bbb625b5b79bdbdefd87e68e15edaa120fe70d4f drm-intel-nightly kernel.

Even with that kernel version, rendering issue still happens on BSW.  On BSW, rendering issue happens *only* in SynMark v7 Terrain tests, not any other tests (including SynMark v6 terrain tests).  I assume issue started at same time on BSW as on BYT (same patch series as flickering), although on BSW it doesn't manifest on other tests that it's visible on BYT.

So far I haven't seen this particular rendering issue on any other machine.

(BYT flickering wasn't affected, it's still as bad.  There's no flickering on BSW.)

Interestingly, I don't see flickering with DRI2, only with DRI3.

DRI2 has another problem, at some point, one fullscreen GL frame gets stuck on screen and nothing else will be visible until X session is restarted.  That issue I've seen earlier also on SKL, at least for a month or two, so it's not impossible that it would be related to this same patchset.

(Reproducing this DRI2 issue on SKL requires running tests for several hours and it cannot be detected by current automation either as tests themselves run fine, that's why it's not bisected.  On BYT the DRI2 issue seems to trigger within more reasonable time though, some minutes.)

Patch du jour:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f547248..eee9dcd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2172,12 +2172,9 @@ static unsigned int intel_surf_alignment(const struct drm_i915_private *dev_priv
                                         uint64_t fb_modifier)
 {
        switch (fb_modifier) {
+       case I915_FORMAT_MOD_X_TILED:
        case DRM_FORMAT_MOD_NONE:
                return intel_linear_alignment(dev_priv);
-       case I915_FORMAT_MOD_X_TILED:
-               if (INTEL_INFO(dev_priv)->gen >= 9)
-                       return 256 * 1024;
-               return 0;
        case I915_FORMAT_MOD_Y_TILED:
        case I915_FORMAT_MOD_Yf_TILED:
                return 1 * 1024 * 1024;


(In reply to Eero Tamminen from comment #11)
> DRI2 has another problem, at some point, one fullscreen GL frame gets stuck
> on screen and nothing else will be visible until X session is restarted. 

The tail of bug 93844:

commit 40e3be34367141c952678f456f0e0d4632b6c266
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 3 10:18:32 2016 +0000

    sna/dri2: Complete the final flip in a chain after the window is destroyed

Not the alignment (but would like to get someone to double check that, we may have been relying on being aligned by the fence).

* egg on face

Checking with VPG, byt is limited to scanning out from the first 256MiB, chv the first 512MiB. More less requires PIN_MAPPABLE, and so one presumes all g4x and earlier.

Reference to Chris' patch: https://patchwork.freedesktop.org/patch/119918/

Luis can you re-test with it?

commit 767a222e47cc13239d38018887f911fec06169ea
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 7 11:01:28 2016 +0000

    drm/i915: Limit Valleyview and earlier to only using mappable scanout
    
    Valleyview appears to be limited to only scanning out from the first 512MiB
    of the Global GTT. Lets presume that this behaviour was inherited from the
    display block copied from g4x (not Ironlake) and all earlier generations
    are similarly affected, though testing suggests different symptoms. For
    simplicity, impose that these platforms must scanout from the mappable
    region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this
    catches Cherryview which does not appear to be limited to the low
    aperture for its scanout.)

The flickering was fixed on BYT two days ago in drm-intel-nightly.
I didn't see any rendering issues after running multiple tests with DRI2 and DRI3.

closing as fixed