Bug 87253 - [BSW drm-intel-fixes]Display is blank after system boots
Summary: [BSW drm-intel-fixes]Display is blank after system boots
Status: CLOSED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: high critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-12 02:46 UTC by Jeff Zheng
Modified: 2017-10-06 14:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg with blank display (83.90 KB, text/plain)
2014-12-12 02:46 UTC, Jeff Zheng
no flags Details

Description Jeff Zheng 2014-12-12 02:46:40 UTC
Created attachment 110765 [details]
dmesg with blank display

==System Environment==
--------------------------
Regression: No. I tried 2014_11_22 and still see this issue.

Non-working platforms: BSW

==kernel==
--------------------------
-nightly: 2014_12_12(works)
-queued: 2014_12_12(works)
-fixes: b0616c5306b342ceca07044dbc4f917d95c4f825 (test fails)

==Bug detailed description==
-----------------------------
After BSW booted, the eDP display is blank. I can ssh to the system.
Only see this issue on drm-intel-fixes branch. -nightly and -queued branchs works.

==Reproduce steps==
---------------------------- 
1. Reboot BSW
Comment 1 Jeff Zheng 2014-12-24 05:22:27 UTC
If DUT connects both HDMI and DP displays, eDP/DP/HDMI screens are all blank.

Official kernel 3.18.0 (commit b2776bf7149bddd1f4161f14f79520f17fc1d71d) has the same issue.
Comment 2 Jani Nikula 2015-01-30 07:05:38 UTC
Please retest with current drm-intel-nightly, and http://patchwork.freedesktop.org/patch/41360
Comment 3 Jeff Zheng 2015-01-30 07:11:14 UTC
Hi Jani,

This issue happens only on 3.18 official kernel and drm-intel-fixes. drm-intel-nightly works. 

Do you suggest to test with latest drm-intel-fixes?
Comment 4 Jani Nikula 2015-01-30 07:18:15 UTC
Ville, do we need to find the commit to backport? This would require a reverse bisect.
Comment 5 Ville Syrjala 2015-01-30 12:43:12 UTC
(In reply to Jani Nikula from comment #4)
> Ville, do we need to find the commit to backport? This would require a
> reverse bisect.

3.18 isn't all that interesting. But if the problem still happens with latest -fixes then a reverse bisect would be a good idea. I just stared at the fixes vs. nightly diff for a while and didn't see anything that would explain it.
Comment 6 Jeff Zheng 2015-02-02 01:50:56 UTC
Tried on drm-intel-fixes 2015_02_01 commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 with latest V55 BIOS, this issue does not exist.
Comment 7 Jani Nikula 2015-02-03 12:15:08 UTC
(In reply to Jeff Zheng from comment #6)
> Tried on drm-intel-fixes 2015_02_01 commit
> 6b96d705f3cf435b0b8835b12c9742513c77fed6 with latest V55 BIOS, this issue
> does not exist.

Closing as NOTOURBUG. I don't think it pays off to bisect to find why the bios vesion matters. Ville, please reopen if you disagree.
Comment 8 Elizabeth 2017-10-06 14:33:05 UTC
Closing old verified.


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.