| Summary: | booting gives black screen [drm:intel_dp_start_link_train] [CONNECTOR:67:eDP-1] Link Training failed at link rate = 162000, lane count = 2 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Seppe <seppe.hoogzaad> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | blocker | ||||||||
| Priority: | medium | CC: | intel-gfx-bugs, jani.nikula, manasi.d.navare | ||||||
| Version: | DRI git | Keywords: | regression | ||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | Triaged, ReadyForDev, | ||||||||
| i915 platform: | BDW | i915 features: | display/eDP | ||||||
| Attachments: |
|
||||||||
|
Description
Seppe
2019-01-20 11:02:56 UTC
I have made a new bug report of a bug triggered by the command: > xset dpms force off The behavior and logs of the bug are similar. I think this is related. This is https://bugs.freedesktop.org/show_bug.cgi?id=109399 I think this is a duplicate of: https://bugs.freedesktop.org/show_bug.cgi?id=109215 solution (on the mainline kernel): git revert 49218c83e25b6f0708f246b07d570b2c43a98223 The problem is caused by the commit 49218c83e25b6f0708f246b07d570b2c43a98223 "drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode". I have not dig into this code, but only tried is reverting helps. It does. The problem is gone without this commit. *** Bug 109399 has been marked as a duplicate of this bug. *** Manasi, patch is yours. Jani, this seems regression. (In reply to Seppe from comment #0) > Created attachment 143169 [details] > log files and computer information Please attach plain text files, one attachment per file. Regression of a fix to another regression, makes your head explode.
When we started to handle clock recovery failures on link training, we knew there were eDP panels out there that failed the initial clock recovery but passed it in the channel equalization phase. We no longer have that failure path within channel equalization.
We failed to root cause the original problem, and added two layers of duct tape on top. So here we are.
---
Please try reverting *both*
1e712535c51a ("drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode")
and
c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP")
How does that work?
Please do *not* use the i915.fastboot parameter for any further testing.
And please add drm.debug=14 module parameter, attach dmesg all the way from boot to the problem. Created attachment 143244 [details]
journal booting the kernel minus two commits
On the stable-kernel i did: > git checkout -b branch.4.20.4.test v4.20.4 > git revert 1e712535c51ab025ebc776d4405683d81521996d Revert "drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode" > git revert c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677 Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" revert I build this kernel with the default .config options for the graphics. Booted with the kernel parameters: splash=silent quiet showopts drm.debug=14 log_buf_len=4M The result: Two white flashes, then a black screen. No logo, no nothing. I could not login remotely. I therefore attached the full log from the journal. The log.txt file shows: Jan 28 21:01:22 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on Jan 28 21:01:25 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on Jan 28 21:02:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on Jan 28 21:02:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on Jan 28 21:03:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on Jan 28 21:03:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on Jan 28 21:04:00 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on Jan 28 21:04:03 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on Jan 28 21:04:30 linux-6axq kernel: [drm:intel_power_well_enable [i915]] enabling always-on Jan 28 21:04:33 linux-6axq kernel: [drm:intel_power_well_disable [i915]] disabling always-on When closing the lid of the laptop, the computer enters state S3. Still the battery consumption is higher than expected. The log then shows the same disable / enable sequence. I assume this is causing the higher than expected battery drain. I thought i would look into this later, but it might be related. (In reply to Jani Nikula from comment #6) > (In reply to Seppe from comment #0) > > Created attachment 143169 [details] > > log files and computer information > > Please attach plain text files, one attachment per file. I have now included a text file. Do you want the previous attachment (the tar.zip files) attached as separate files? Or did you mean just the new ones? You cannot absolutely revert the "drm/i915/edp: Do not do link training fallback or prune modes on EDP" this patch since now with reverting this, it is falling back to lower value and pruning out the only native mode on the panel. I think clearly this is a panel where we need to follow a sequence of retrying the CR after 5 failures on Channel EQ. To test this we will need to revert all the patches that fix the CR and Channel EQ sequencing for compliance. Let me also meanwhile try to create a patch that retries CR after Channel EQ failure. Manasi For me this can be marked as solved I have changed/updated the BIOS to an UEFI one (and also updated the system). This because the kernel sometimes failed to load a hibernate image. Errors in dmesg then pointing at BIOS errors. These were the following two errors: : Hibernate inconsistent memory map detected! : PM: Image mismatch: architecture specific data I was using the BIOS from the "Install/Update RW_LEGACY Firmware" option from Mr Chromebox ChromeOS Firmware Utility Script (https://mrchromebox.tech/#fwscript). I replaced this BIOS with "Full ROM firmware" option from the same script. This essentially replaced the whole BIOS with a new UEFI based one. This required me to remove the write-protect screw from my Dell Chromebook. After reinstalling the system (required because of the UEFI system) i found that the new BIOS solved my hibernate problem, but also the black screen problem described on the page here. This was surprising for me, since the RW_LEGACY option is a normal option to use and i could not find bad side effects of it on the internet. I did not thought that changing the BIOS would also solve the "Black screen" problem described here. Else i would have tried this earlier. I can now conclude that also changing something in the BIOS, solves this problem, apart from the "git revert 49218c83e25b6f0708f246b07d570b2c43a98223" solution. I will no longer be able to reproduce the error. Only by flashing back the original BIOS and reinstall the system, this could be done. This is to much work for me. I can not change the status to "solved", i therefore leave it as it is. If additional information is required i can provide it. Thanks for your feedback Seppe. To proceed further we need a reproducer. Until then I can close this issue. Please reopen the issue if it occurs with latest drmtip. (https://cgit.freedesktop.org/drm-tip) Remember to attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M. |
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.