Bug 43348

Summary:	[ILK dp] blank screen at boot after kms
Product:	Drivers	Reporter:	Matthieu Imbert (matthieu.imbert)
Component:	Video(DRI - Intel)	Assignee:	drivers_video-dri-intel (drivers_video-dri-intel)
Status:	RESOLVED OBSOLETE
Severity:	high	CC:	chris, daniel
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.2.0	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	full dmesg of failed KMS during boot with drm.debug=0xe full dmesg of successful KMS during boot with drm.debug=0xe

Description Matthieu Imbert 2012-06-07 11:12:45 UTC

Hardware: Dell E4310 laptop with integrated Intel HD Graphics Chipset

When i boot, more than 50% of the time, KMS fails for the laptop screen, with message:
[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting

Then, the screen is either black or contains some garbage. I'm able to get other the issue by putting the laptop in software suspend and immediately resume it, then i get back a correct screen.

If needed, i can compile a kernel with patches or another kernel version to check.

Comment 1 Chris Wilson 2012-06-07 11:14:59 UTC

3.2 is notorious for its DP regressions, can you please retest with say 3.4?

Comment 2 Daniel Vetter 2012-06-07 12:01:07 UTC

Also, please attach full dmesg with drm.debug=0xe added to your kernel cmdline.

Comment 3 Matthieu Imbert 2012-06-08 06:20:29 UTC

Ok, i will test with 3.4.

In the meantime, i attach two full dmesg with drm.debug=0xe. One dmesg is for a successful KMS during boot, the other is for a failed KMS during boot.

Since I added drm.debug=0xe, the frequency of KMS failure at boot time is noticeably lower. It was more than 50% before (perhaps 60% to 70%), it is now something like 10%

Comment 4 Matthieu Imbert 2012-06-08 06:22:18 UTC

Created attachment 73540 [details]
full dmesg of failed KMS during boot with drm.debug=0xe

Comment 5 Matthieu Imbert 2012-06-08 06:22:40 UTC

Created attachment 73541 [details]
full dmesg of successful KMS during boot with drm.debug=0xe

Comment 6 Matthieu Imbert 2012-06-28 09:10:51 UTC

This bug is fixed with 3.2.20 (tested with the latest debian kernel linux-image-3.2.0-2-rt-amd64 version 3.2.20-1)