Bug 73539

Summary: [Haswell regression] eDP panel blank screen: link train fails
Product: DRI Reporter: Steve Williams <steve>
Component: DRM/IntelAssignee: Paulo Zanoni <przanoni>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: anewgene+freedesktop, burian, intel-gfx-bugs, przanoni, steve
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output
none
kern.log file
none
register dump booted with nomodeset
none
register dump without nomodeset (black screen)
none
new regdump without nomodeset kernel parameter (black screen)
none
new regdump with nomodeset kernel parameter
none
output of intel_reg_dumper
none
Workaround: Unconditionally activate all lanes on eDP port
none
contents of /sys/kernel/debug/dri/0/i915_opregion booted with uefi
none
contents of /sys/kernel/debug/dri/0/i915_opregion booted with legacy bios none

Description Steve Williams 2014-01-13 08:48:00 UTC
Created attachment 91929 [details]
dmesg output

Tested on Dell Venue 11 Pro tablet (Haswell i5 4210Y, Intel HD4200).

Tested this with the following distros, all with various versions of Xorg and Linux Kernel.

Ubuntu 14.04 (daily iso build, up to latest)
Ubuntu 13.04
Ubuntu 12.04.3
Fedora 20 daily build
Debian Wheezy
Arch Linux daily build

With "nomodeset", I get varying levels of success when booting from legacy mode. when booting with UEFI, I've had no such luck.

The only common error I've found across many of the distros is the following error: 

[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[drm:intel_dp_start_link_train], too many full retries, give up
Comment 1 Steve Williams 2014-01-13 10:42:27 UTC
Created attachment 91941 [details]
kern.log file

my kern.log output too (Ubuntu 14.04 daily build)
Comment 2 Paulo Zanoni 2014-01-13 14:24:24 UTC
PSR panel.
337500KHz CDCLK.
18bpp + dither.
PCI ID ending in 0xE.

All the unusual stuff together...
Comment 3 Steve Williams 2014-01-14 06:05:40 UTC
Is this a no hope case or just a difficult one to solve?

Is there anything that I can do in the meantime to further identify the bug?
Comment 4 Daniel Vetter 2014-01-14 10:36:32 UTC
Please grab latest intel-gpu-tools and attach the output of intel_reg_dumper for both the working and the broken case.
Comment 5 Jani Nikula 2014-01-14 12:17:53 UTC
Have you tried kernel version v3.13-rc1 or later?
Comment 6 Jani Nikula 2014-01-21 11:58:17 UTC
(In reply to comment #2)
> All the unusual stuff together...

Paulo seems to know about this...
Comment 7 Markus Blank-Burian 2014-02-01 23:04:25 UTC
Created attachment 93199 [details]
register dump booted with nomodeset
Comment 8 Markus Blank-Burian 2014-02-01 23:05:04 UTC
Created attachment 93200 [details]
register dump without nomodeset (black screen)
Comment 9 Markus Blank-Burian 2014-02-01 23:23:36 UTC
I ran into the same problem on 3.13.1. Also tested drm-intel-fixes, but still not fixed there. For more information, I created register dumps booting with and without "nomodeset" kernel parameter.
Comment 10 Paulo Zanoni 2014-02-06 12:59:35 UTC
Reg dumper says "Dumping from file without -d argument. Assuming Ironlake machine.". Something seems wrong. How did you run intel-reg-dumper?

Please just do "sudo ./intel_reg_dumper > file" and we should be fine.
Comment 11 Markus Blank-Burian 2014-02-06 13:50:18 UTC
Created attachment 93527 [details]
new regdump without nomodeset kernel parameter (black screen)
Comment 12 Markus Blank-Burian 2014-02-06 13:50:56 UTC
Created attachment 93528 [details]
new regdump with nomodeset kernel parameter
Comment 13 Markus Blank-Burian 2014-02-06 13:53:03 UTC
I had an old version of intel_gpu_tools and dumped the registers to file before running the reg_dumper. Generated both new dumps directly with version 1.5.
Comment 14 Steve Williams 2014-02-25 20:20:17 UTC
Created attachment 94727 [details]
output of intel_reg_dumper

this is the attachment of the requested output from running "sudo intel_reg_dumper > log"
Comment 15 Markus Blank-Burian 2014-03-08 01:01:21 UTC
Looking at the dumps, I found, that there are only 2 lanes activated. Increasing the intel_dp->lane_count to max_lane_count during the initialization in intel_dp_compute_config resolves this issue and link training succeeds.
Comment 16 Jani Nikula 2014-03-12 12:15:25 UTC
Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel.
Comment 17 Markus Blank-Burian 2014-03-12 15:26:51 UTC
This problem was still not fixed in the nightly branch 4 days ago, when i found this workaround. I will try again within the next few days and post the results.
Comment 18 Markus Blank-Burian 2014-03-15 01:15:41 UTC
update on the current state of the nightly branch: 
kernel hangs at boot since commit 294ae7b44bba7ab0d4cef9a8736287f38bdb4fd without any BUG/OOPS/WARN and also without output from drm.debug=0xe

link training still failed until the commit before that: b2040f6fed736ccd2319768bc59833abe74148b8
Comment 19 Markus Blank-Burian 2014-03-15 01:23:08 UTC
Created attachment 95839 [details]
Workaround: Unconditionally activate all lanes on eDP port

This is the quick hack i made to activate "max_lane_count" lanes for link training to succeed.
Comment 20 Daniel Vetter 2014-03-27 09:49:23 UTC
Aside: Same issue seems to happen on bdw, too.

Looking at the provided register dumps the bios indeed goes with a 4x lane config. I guess we finally need to implement that bit of spec language that says if link training fails we need to retry with lowered clocks.
Comment 21 Jani Nikula 2014-04-22 16:26:31 UTC
Markus, please attach /sys/kernel/debug/dri/0/i915_opregion.

If it's not too much trouble, please check if it's different for legacy boot vs. UEFI, and if there's a difference, please attach both. Thanks.
Comment 22 Jani Nikula 2014-04-22 17:22:37 UTC
Please try the two patches attached to bug 76711 and report back.
(https://bugs.freedesktop.org/show_bug.cgi?id=76711#c14)
Comment 23 Markus Blank-Burian 2014-04-22 20:44:36 UTC
Created attachment 97772 [details]
contents of /sys/kernel/debug/dri/0/i915_opregion booted with uefi
Comment 24 Markus Blank-Burian 2014-04-22 20:45:06 UTC
Created attachment 97773 [details]
contents of /sys/kernel/debug/dri/0/i915_opregion booted with legacy bios
Comment 25 Markus Blank-Burian 2014-04-22 20:58:01 UTC
with both your patches applied to 3.14.0, link train succeeds perfectly on my machine.
Comment 26 Jani Nikula 2014-04-23 05:40:11 UTC
(In reply to comment #25)
> with both your patches applied to 3.14.0, link train succeeds perfectly on
> my machine.

Daniel, take note: 3.14 did not even prefer fast over wide yet.
Comment 27 Jani Nikula 2014-04-23 08:57:51 UTC
(In reply to comment #25)
> with both your patches applied to 3.14.0, link train succeeds perfectly on
> my machine.

Wait. The patches do not apply cleanly on 3.14. Does unpatched vanilla v3.15-rc2 work for you?
Comment 28 Markus Blank-Burian 2014-04-23 09:04:01 UTC
I merged the patch into the kernel by hand "patch -p1 -l --merge < ..."

I will post the results for 3.15-rc2 this evening
Comment 29 Markus Blank-Burian 2014-04-24 08:51:44 UTC
v3.15-rc2 unpatched does not work
v3.15-rc2 patched works fine
Comment 30 Jani Nikula 2014-04-25 07:15:05 UTC
Markus, please try http://patchwork.freedesktop.org/patch/24813/ (and only that patch) on otherwise unpatched 3.14 and 3.15-rc2. Thanks.
Comment 31 Markus Blank-Burian 2014-04-25 22:04:03 UTC
the max_lane_count has already the correct value (4), so the last mentioned patch has no effect here. but tested anyway on v3.15-rc2 without success.
Comment 32 Jani Nikula 2014-05-06 17:03:49 UTC
commit 0aa7de323a32ca0b27769901b9607fc892b90dbc
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue May 6 14:56:52 2014 +0300

    drm/i915: use lane count and link rate from VBT as minimums for eDP

pushed to drm-intel-fixes (and updated to drm-intel-nightly) branch of http://cgit.freedesktop.org/drm-intel.

Markus, as this will be queued for 3.15, I would very much appreciate it if you could verify that either of the branches now work for you. Thanks.
Comment 33 Markus Blank-Burian 2014-05-06 19:46:31 UTC
I just tested drm-intel-fixes and it works fine. Thank you very much for your patches!
Comment 34 Jani Nikula 2014-05-07 07:13:37 UTC
(In reply to comment #33)
> I just tested drm-intel-fixes and it works fine. Thank you very much for
> your patches!

No, thank you very much for testing! ;)
Comment 35 Jari Tahvanainen 2017-01-12 15:01:01 UTC
Closing resolved+fixed. Verified by second reporter.

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.