| Summary: | [CFL] Screen goes blank right after boot. | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Kai-Heng Feng <kai.heng.feng> | ||||||||||||||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||
| Severity: | critical | ||||||||||||||||||||||
| Priority: | high | CC: | intel-gfx-bugs, kai.heng.feng, tjaalton, zorg1331 | ||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||
| Hardware: | Other | ||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||
| Whiteboard: | ReadyForDev | ||||||||||||||||||||||
| i915 platform: | CFL | i915 features: | display/Other | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Kai-Heng Feng
2017-12-06 05:14:49 UTC
Created attachment 135993 [details]
dmesg with drm.debug=0x0e
BTW it's not a regression, I tried latest drm-intel because I can see the same issue on v4.13 based kernel. The awkward part here is: [ 6.838832] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x6 for port D (VBT) !!! This pin is totally wrong hence hdmi communication doesn't work.... We will need to add some prints to debug and understand how this was possible.... (In reply to Rodrigo Vivi from comment #3) > We will need to add some prints to debug and understand how this was > possible.... Can you advise me where to add these debug prints? Or better yet, can you provide a patch to do the debug prints? Thanks. The new VBIOS fixed the issue. Thanks! Hi Rodrigo, The original one (In reply to Kai-Heng Feng from comment #5) > The new VBIOS fixed the issue. Turns out ODM just disable unused HDMI port, and workaround issue. Now we are enabling a new CFL platform, same issue can be observed on this CFL platform. This new platform requires HDMI output, so we can't simply disable it in VBIOS. Do you have any suggestion? Thanks. Sorry for not getting back sooner here...
So, VBT on this platform is bugged for sure. 6 is an invalid pin.
Anyways I double checked the code here and it is not possible if you have latest code there.
Since you are running with
4.14.0-rc7+
you probably have this patch applied:
75be7756bc21 ("drm/i915/cnl: Don't trust VBT's alternate pin for port D for now.")
but you are probably missing the proper fix:
9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
Also probably a good idea to apply this one:
c4fb60b9aba9 ("drm/i915/bios: add DP max link rate to VBT child device struct")
Could you please apply both patches and retest?
(In reply to Rodrigo Vivi from comment #7) > Sorry for not getting back sooner here... > > So, VBT on this platform is bugged for sure. 6 is an invalid pin. > > Anyways I double checked the code here and it is not possible if you have > latest code there. > > Since you are running with > 4.14.0-rc7+ The kernel I used is from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/. Those kernels are built against intel-nightly tags. So the DRM and I915 are much newer than v4.14.0-rc7+. I'll ask if put intel-nightly tags into version string is possible... > > you probably have this patch applied: > 75be7756bc21 ("drm/i915/cnl: Don't trust VBT's alternate pin for port D for > now.") > > but you are probably missing the proper fix: > 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") > > Also probably a good idea to apply this one: > c4fb60b9aba9 ("drm/i915/bios: add DP max link rate to VBT child device > struct") > > Could you please apply both patches and retest? Sure. The new one is built against drm-intel-next-queued: commit c4fb60b9aba9f939d3f8575df23fd8d5958ec6ed (drm-intel/drm-intel-next-queued) Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Jan 18 17:33:10 2018 +0200 drm/i915/bios: add DP max link rate to VBT child device struct But the same code trace can be observed. Please see attached dmesg. Also, this issue only happens when "Legacy ROM boot support" is enabled. Created attachment 136841 [details]
dmesg, commit c4fb60b9aba9f939d3f8575df23fd8d5958ec6ed
Please boot again with drm.debug=0x1e for proper dmesg logs. Created attachment 136843 [details]
dmesg with drm.debug=0x1e
[drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x6 for port D (VBT)
makes me think that you are still missing one patch on your tree:
9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
could you please double check?
Also, is it possible to test with drm-tip branch?
cgit.freedesktop.org/drm/drm-tip
drm-intel-nightly doesn't exist anymore, so I don't know exactly the code that your tree there is fetching.
Thanks
(In reply to Rodrigo Vivi from comment #12) > [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x6 for port D (VBT) > > makes me think that you are still missing one patch on your tree: > > 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") > > could you please double check? I can confirm it's in the tree. > > Also, is it possible to test with drm-tip branch? > cgit.freedesktop.org/drm/drm-tip Sure, I'll use this branch to test again. > > drm-intel-nightly doesn't exist anymore, so I don't know exactly the code > that your tree there is fetching. Like my previous comment, the kernel was built against this commit: commit c4fb60b9aba9f939d3f8575df23fd8d5958ec6ed (drm-intel/drm-intel-next-queued) Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Jan 18 17:33:10 2018 +0200 drm/i915/bios: add DP max link rate to VBT child device struct All three commits you mentioned are included. The nightly part was to explain how kernel in [1] gets built. It's kinda irrelevant in this context though. [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/. > > Thanks Created attachment 136853 [details] [review] Ignore invalid pin. Hmm... that patch I mentioned check the boundaries for returning the valid ones, but doesn't check them to avoid VBT for messing up the pins actually. So, could you please try this attached patch? If that still doesn't work please fwd me the logs with drm.debug=0x1e please. Thanks, Rodrigo. Created attachment 136887 [details]
dmesg with drm.debug=0x1e, patch applied
This patch does solve the issue.
Thanks!
Please attach a copy of /sys/kernel/debug/dri/0/i915_opregion Created attachment 136933 [details]
i915_opregion
Created attachment 136935 [details]
i915_vbt
I hope the fixes that aren't in 4.15 get there via stable@, since CNP is shared with CFL which is enabled there. (In reply to Kai-Heng Feng from comment #8) > Also, this issue only happens when "Legacy ROM boot support" is enabled. Are you saying you're legacy booting instead of UEFI? If the laptop came with preinstalled Windows and UEFI boot, all bets are off when you try to use legacy bios boot with Linux. It's likely the VBT is *different* for UEFI and legacy boot, and typically the legacy boot one wasn't even tested. (In reply to Jani Nikula from comment #20) > (In reply to Kai-Heng Feng from comment #8) > > Also, this issue only happens when "Legacy ROM boot support" is enabled. > > Are you saying you're legacy booting instead of UEFI? No, the system in question still boots under UEFI mode. When BIOS option "Legacy ROM boot support" is checked, the system support to boot under both legacy and UEFI mode. But we still boot the system through UEFI. > > If the laptop came with preinstalled Windows and UEFI boot, all bets are off > when you try to use legacy bios boot with Linux. It's likely the VBT is > *different* for UEFI and legacy boot, and typically the legacy boot one > wasn't even tested. (In reply to Kai-Heng Feng from comment #21) > (In reply to Jani Nikula from comment #20) > > (In reply to Kai-Heng Feng from comment #8) > > > Also, this issue only happens when "Legacy ROM boot support" is enabled. > > > > Are you saying you're legacy booting instead of UEFI? > > No, the system in question still boots under UEFI mode. > > When BIOS option "Legacy ROM boot support" is checked, the system support to > boot under both legacy and UEFI mode. But we still boot the system through > UEFI. Please attach /sys/kernel/debug/dri/0/i915_vbt with both settings. Please mark clearly which is which. Fixed with:
a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")
which got fixed by: 3393ce1ed8fc ("drm/i915/cnp: Properly handle VBT ddc pin out of bounds.")
Feel free to reopen in case this is still seen on trees with these patches applied.
Created attachment 137708 [details]
Legacy Boot ROM disabled
Sorry for the late reply. I was on vacation, so no physical access to the system.
Created attachment 137709 [details]
Legacy Boot ROM enabled
Attach i915_vbt when Legacy boot ROM is enabled/disabled.
(In reply to Rodrigo Vivi from comment #23) > Feel free to reopen in case this is still seen on trees with these patches > applied. I just want to mention that I had the similar problem on a laptop Dell Lattitude 5590 with "Intel Corporation UHD Graphics 620 (rev 07)". Luckily I was able to find this bug report and fixed it by applying patch from https://patchwork.kernel.org/patch/10003565/ "drm/i915: check pin validity of VBT configurationlogin". I applied the patch to v4.16 linux kernel tag, so it requires small modifications. I see that https://patchwork.kernel.org/patch/10180851/ "drm/i915/cnp: Ignore VBT request for know invalid DDC pin." could help, but it seems more like a quirk. Could someone promote these solutions into mainline/longterm kernels? Or it is already in queue and will be included in next releases? right, I replied to the patch thread asking if it should be sent for stable, but got no reply (In reply to Timo Aaltonen from comment #27) > right, I replied to the patch thread asking if it should be sent for stable, > but got no reply Yeah, sorry about that. The relevant commits are in v4.16: 6e3322c226f1 ("drm/i915/cnp: Properly handle VBT ddc pin out of bounds.") f24c606c21a8 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") I've made a stable backport request for v4.15. (In reply to Jani Nikula from comment #28) > (In reply to Timo Aaltonen from comment #27) > > right, I replied to the patch thread asking if it should be sent for stable, > > but got no reply > > Yeah, sorry about that. The relevant commits are in v4.16: > > 6e3322c226f1 ("drm/i915/cnp: Properly handle VBT ddc pin out of bounds.") > f24c606c21a8 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") > > I've made a stable backport request for v4.15. Thank you. However, in my personal case (Dell 5590 laptop with "Intel Corporation UHD Graphics 620 (rev 07)" card), the mentioned patches not enough to solve the problem. I experience the same error as in the original bug report. The only solution that works for me for v4.16 and v4.14 kernels is to apply the patch from https://patchwork.kernel.org/patch/10003565/ "drm/i915: check pin validity of VBT configurationlogin". From my point of view "6e3322c226f1" and "f24c606c21a8" contain slightly less quirks comparing to the patch that helped me. Could someone with good knowledge of this subsystem decide if it should also be included into the mainline/stable? (In reply to Pavel Nakonechnyi from comment #29) > (In reply to Jani Nikula from comment #28) > > (In reply to Timo Aaltonen from comment #27) > > > right, I replied to the patch thread asking if it should be sent for stable, > > > but got no reply > > > > Yeah, sorry about that. The relevant commits are in v4.16: > > > > 6e3322c226f1 ("drm/i915/cnp: Properly handle VBT ddc pin out of bounds.") > > f24c606c21a8 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") > > > > I've made a stable backport request for v4.15. > > Thank you. > > However, in my personal case (Dell 5590 laptop with "Intel Corporation UHD > Graphics 620 (rev 07)" card), the mentioned patches not enough to solve the > problem. > > I experience the same error as in the original bug report. The only solution > that works for me for v4.16 and v4.14 kernels is to apply the patch from > https://patchwork.kernel.org/patch/10003565/ "drm/i915: check pin validity > of VBT configurationlogin". > > From my point of view "6e3322c226f1" and "f24c606c21a8" contain slightly > less quirks comparing to the patch that helped me. > > Could someone with good knowledge of this subsystem decide if it should also > be included into the mainline/stable? The patch is not even upstream. The two commits apparently helped the original reporter, so it seems to me you have a different root cause. Please file a new bug, add dmesg with drm.debug=14, attach /sys/kernel/debug/dri/0/i915_vbt. Are you doing UEFI boot? If not, please try. PS. We don't support CFL in v4.14 upstream. (In reply to Jani Nikula from comment #30) > Please file a new bug, add dmesg with drm.debug=14, attach > /sys/kernel/debug/dri/0/i915_vbt. > > Are you doing UEFI boot? If not, please try. Filed a new bug: https://bugs.freedesktop.org/show_bug.cgi?id=105961 |
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.