Bug 105178 - [CNL] Corruption is seen on desktop after boot up
Summary: [CNL] Corruption is seen on desktop after boot up
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords: bisect_pending, regression
Depends on:
Blocks:
 
Reported: 2018-02-20 21:45 UTC by Luis Botello
Modified: 2018-04-04 10:40 UTC (History)
1 user (show)

See Also:
i915 platform: CNL
i915 features: display/eDP


Attachments
corruption_picture (172.89 KB, image/jpeg)
2018-02-20 21:45 UTC, Luis Botello
no flags Details
kernel_log (406.30 KB, text/plain)
2018-02-20 21:45 UTC, Luis Botello
no flags Details

Description Luis Botello 2018-02-20 21:45:07 UTC
Created attachment 137481 [details]
corruption_picture

Software Configuration:
--------------
kernel version              : 4.16.0-rc1-drm-intel-qa-ww8-commit-67f1480+
architecture                : x86_64
os version                  : Ubuntu 17.10
bios revision               : 124.2
ksc                         : 1.36

Hardware configuration
----------------------
motherboard model          : CannonLakeClientPlatform
manufacturer               : IntelCorporation
gpu card                   : Intel Corporation Device 5a49 (rev 03) (prog-if 00 [VGA controller])
cpu thread                 : 4
cpu core                   : 2

Steps:
------
1 - Install latest drm-tip kernel
2 - Boot up platform

Bug description:
---------------
Corruption is seen on desktop after system boots up.
Comment 1 Luis Botello 2018-02-20 21:45:37 UTC
Created attachment 137482 [details]
kernel_log
Comment 2 Rodrigo Vivi 2018-02-28 22:31:24 UTC
That's a really bad picture :(

I think the priority here should be raised.

Logs doesn't give much information. IS it reproducible 100% of the time?
Still with latest drm-tip?

Probably a regression, right? If so, could you please bisect it to find the original first bad commit?
Comment 3 Elizabeth 2018-03-01 23:23:24 UTC
As reference:
Last good known commit:
commit 1cf237a2160af1a670d75523e073ff8614780b99
Author:     Rodrigo Vivi <rodrigo.vivi@intel.com>
AuthorDate: Wed Feb 14 11:44:40 2018 -0800
Commit:     Rodrigo Vivi <rodrigo.vivi@intel.com>
CommitDate: Wed Feb 14 11:44:40 2018 -0800

    drm-tip: 2018y-02m-14d-19h-43m-47s UTC integration manifest

Possible first bad known commit:
commit bd16af128e78b302b3034fa85626cd15dcf5f038
Author:     Rodrigo Vivi <rodrigo.vivi@intel.com>
AuthorDate: Wed Feb 14 16:23:29 2018 -0800
Commit:     Rodrigo Vivi <rodrigo.vivi@intel.com>
CommitDate: Wed Feb 14 16:23:29 2018 -0800

    drm-tip: 2018y-02m-15d-00h-22m-40s UTC integration manifest
Comment 4 Rodrigo Vivi 2018-03-01 23:58:41 UTC
This bisect is probably wrong.

First of all it is a bad idea to referrence the bisect as the drm-tip
head. Luckly I was the one that generated it so I have the local referrence.

But also I can see here that latest patch on this drm-tip pointed as bad is:
drm/i915/cnl: Remove alpha_support protection
and
drm/i915/cnl: Sync PCI ID with Spec.

So I guess the bisect is being run without i915.alpha_support=1
Hence the false impression graphics was working, but only with VESA.
Comment 5 Elizabeth 2018-03-02 15:32:24 UTC
(In reply to Rodrigo Vivi from comment #4)
> This bisect is probably wrong.
> 
> First of all it is a bad idea to referrence the bisect as the drm-tip
> head. Luckly I was the one that generated it so I have the local referrence.
> 
> But also I can see here that latest patch on this drm-tip pointed as bad is:
> drm/i915/cnl: Remove alpha_support protection
> and
> drm/i915/cnl: Sync PCI ID with Spec.
> 
> So I guess the bisect is being run without i915.alpha_support=1
> Hence the false impression graphics was working, but only with VESA.

Sorry for the confusion, is not a bisect, they are only the commit information of the last kernel compiled that we had available to test without corruption, and the first one where it started to show.
Our CNLs are busy now running some tests so at the moment we cannot bisect. I should have been more specific, sorry again :O
Comment 6 Jani Saarinen 2018-03-29 07:11:39 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 7 Armando Antonio 2018-04-02 14:15:00 UTC
Hello, 

I tried to reproduce this issue with the following configurations and currently the corruption didn't appear, 

==============================
Graphic Stack versions
==============================
Cairo- 1.15.8-123-g5454b85d4
drm - libdrm-2.4.91-10-ga58490de
igt = intel-gpu-tools-1.22-18-g5c146fcf
vaapi - 2.1.0-37-g65ee298
libinput - 1.10.0-74-ge4ce6dfb
libva - 2.1.0-6-g88084bc
libva-utils - 2.1.0-2-gc77a46c
libXfont - libXfont2-2.0.3
macros - util-macros-1.19.2
xf86-input-evdev-2.10.5-5-gab1d9ad
xf86-input-libinput-0.26.0-3-g9d9f59f
xf86-video-fbdev-0.4.4-13-g9af7f81
xf86-video-intel - 2.99.917-814-gaa36399c
xf86-video-vesa-2.4.0
xorgproto - xorgproto-2018.4-1-g702d2ea
xserver - xorg-server-1.19.99.901-29-gedf08bd65
mesa - 17.3-branchpoint-3960-g03e37ec6d7

===============================
Kernel version
===============================

commit 307515cd9c5a0464cca2a5257fddacf6dbb0fed6
Author:     Maxime Ripard <maxime.ripard@bootlin.com>
AuthorDate: Wed Mar 14 09:49:14 2018 +0100
Commit:     Maxime Ripard <maxime.ripard@bootlin.com>
CommitDate: Wed Mar 14 09:49:14 2018 +0100

    drm-tip: 2018y-03m-14d-08h-47m-52s UTC integration manifest


closed as fixed since new kernel version seems to have fixed it.


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.