Kernel: drm/drm-intel drm-intel-next-queued branch Firmware: drm/drm-firmware master branch Once the i915 is loaded, the screen goes full blank. I can see the trace from i915: [ 7.206826] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin)) [ 7.206837] ------------[ cut here ]------------ [ 7.206860] WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_i2c.c:741 intel_gmbus_get_adapter+0x43/0x50 [i915] [ 7.206861] Modules linked in: hid_multitouch dell_wmi wmi_bmof mxm_wmi nls_iso8859_1 intel_rapl dell_laptop x86_pkg_temp_thermal dell_smbios intel_powerclamp dcdbas coretemp i915 kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul snd_hwdep crc32_pclmul snd_hda_core ghash_clmulni_intel pcbc aesni_intel snd_pcm aes_x86_64 crypto_simd cryptd glue_helper intel_cstate snd_seq intel_rapl_perf snd_timer i2c_algo_bit snd_seq_device joydev drm_kms_helper input_leds snd serio_raw soundcore syscopyarea sysfillrect idma64 sysimgblt fb_sys_fops virt_dma drm intel_lpss_pci intel_lpss shpchp processor_thermal_device intel_soc_dts_iosf int3403_thermal int340x_thermal_zone wmi intel_hid int3400_thermal mac_hid sparse_keymap acpi_thermal_rel acpi_pad parport_pc ppdev lp parport autofs4 btrfs xor [ 7.206885] zstd_compress raid6_pq dm_mirror dm_region_hash dm_log psmouse alx ahci mdio libahci i2c_hid video hid pinctrl_cannonlake pinctrl_intel [ 7.206892] CPU: 3 PID: 305 Comm: kworker/u24:4 Not tainted 4.14.0-rc7+ #1 [ 7.206892] Hardware name: Dell Inc. G7 7587/ , BIOS 0.2.1 11/15/2017 [ 7.206895] Workqueue: events_unbound async_run_entry_fn [ 7.206896] task: ffff9d55d94e2f00 task.stack: ffffad6ec3acc000 [ 7.206918] RIP: 0010:intel_gmbus_get_adapter+0x43/0x50 [i915] [ 7.206918] RSP: 0018:ffffad6ec3acfb90 EFLAGS: 00010286 [ 7.206919] RAX: 0000000000000031 RBX: 0000000000000006 RCX: ffffffffbb85fd48 [ 7.206920] RDX: 0000000000000000 RSI: 0000000000000096 RDI: 0000000000000202 [ 7.206920] RBP: ffffad6ec3acfba0 R08: 0000000000000031 R09: 00000000000004a9 [ 7.206921] R10: ffffad6ec3acfbd0 R11: 0000000000000031 R12: ffff9d55ccfe0000 [ 7.206921] R13: ffff9d55ccfe0000 R14: ffff9d55cd4bf000 R15: ffffffffc1053e00 [ 7.206922] FS: 0000000000000000(0000) GS:ffff9d55ddac0000(0000) knlGS:0000000000000000 [ 7.206923] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.206923] CR2: 00007fa638d56624 CR3: 0000000491409003 CR4: 00000000003606e0 [ 7.206924] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7.206925] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 7.206925] Call Trace: [ 7.206947] intel_hdmi_set_edid+0x3f/0x1c0 [i915] [ 7.206966] intel_hdmi_detect+0x8d/0xb0 [i915] [ 7.206970] drm_helper_probe_detect+0x75/0xa0 [drm_kms_helper] [ 7.206973] drm_helper_probe_single_connector_modes+0xee/0x730 [drm_kms_helper] [ 7.206977] drm_setup_crtcs+0x139/0x9e0 [drm_kms_helper] [ 7.206981] __drm_fb_helper_initial_config_and_unlock+0x3f/0x3b0 [drm_kms_helper] [ 7.206983] ? __switch_to+0x1f3/0x4d0 [ 7.206986] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] [ 7.207009] intel_fbdev_initial_config+0x18/0x30 [i915] [ 7.207011] async_run_entry_fn+0x36/0x150 [ 7.207013] process_one_work+0x156/0x3f0 [ 7.207014] worker_thread+0x4b/0x460 [ 7.207015] kthread+0x109/0x140 [ 7.207016] ? process_one_work+0x3f0/0x3f0 [ 7.207017] ? kthread_create_on_node+0x70/0x70 [ 7.207019] ret_from_fork+0x25/0x30 [ 7.207020] Code: 84 c0 74 14 48 69 db 48 04 00 00 49 8d 84 1c a8 0b 00 00 5b 41 5c 5d c3 48 c7 c6 08 27 07 c1 48 c7 c7 36 38 08 c1 e8 de c3 ad f9 <0f> ff 31 c0 5b 41 5c 5d c3 0f 1f 40 00 0f 1f 44 00 00 8b 87 f4 [ 7.207039] ---[ end trace 694c65d4d242db88 ]--- [ 7.207041] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 7.207047] IP: i2c_transfer+0xe/0xc0 [ 7.207048] PGD 0 P4D 0 [ 7.207050] Oops: 0000 [#1] SMP [ 7.207051] Modules linked in: hid_multitouch dell_wmi wmi_bmof mxm_wmi nls_iso8859_1 intel_rapl dell_laptop x86_pkg_temp_thermal dell_smbios intel_powerclamp dcdbas coretemp i915 kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul snd_hwdep crc32_pclmul snd_hda_core ghash_clmulni_intel pcbc aesni_intel snd_pcm aes_x86_64 crypto_simd cryptd glue_helper intel_cstate snd_seq intel_rapl_perf snd_timer i2c_algo_bit snd_seq_device joydev drm_kms_helper input_leds snd serio_raw soundcore syscopyarea sysfillrect idma64 sysimgblt fb_sys_fops virt_dma drm intel_lpss_pci intel_lpss shpchp processor_thermal_device intel_soc_dts_iosf int3403_thermal int340x_thermal_zone wmi intel_hid int3400_thermal mac_hid sparse_keymap acpi_thermal_rel acpi_pad parport_pc ppdev lp parport autofs4 btrfs xor [ 7.207078] zstd_compress raid6_pq dm_mirror dm_region_hash dm_log psmouse alx ahci mdio libahci i2c_hid video hid pinctrl_cannonlake pinctrl_intel [ 7.207084] CPU: 3 PID: 305 Comm: kworker/u24:4 Tainted: G W 4.14.0-rc7+ #1 [ 7.207086] Hardware name: Dell Inc. G7 7587/ , BIOS 0.2.1 11/15/2017 [ 7.207089] Workqueue: events_unbound async_run_entry_fn [ 7.207090] task: ffff9d55d94e2f00 task.stack: ffffad6ec3acc000 [ 7.207093] RIP: 0010:i2c_transfer+0xe/0xc0 [ 7.207094] RSP: 0018:ffffad6ec3acfa78 EFLAGS: 00010246 [ 7.207096] RAX: 0000000000000001 RBX: 0000000000000005 RCX: 0000000000000001 [ 7.207097] RDX: 0000000000000002 RSI: ffffad6ec3acfad0 RDI: 0000000000000000 [ 7.207099] RBP: ffffad6ec3acfa90 R08: 0000000000000001 R09: 0000000000000050 [ 7.207100] R10: 0000000000000001 R11: 0000000000000031 R12: 0000000000000002 [ 7.207102] R13: ffffad6ec3acfabe R14: ffffad6ec3acfabf R15: ffffad6ec3acfb6f [ 7.207103] FS: 0000000000000000(0000) GS:ffff9d55ddac0000(0000) knlGS:0000000000000000 [ 7.207105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.207107] CR2: 0000000000000010 CR3: 0000000491409003 CR4: 00000000003606e0 [ 7.207108] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7.207110] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 7.207111] Call Trace: [ 7.207121] drm_do_probe_ddc_edid+0xed/0x160 [drm] [ 7.207129] drm_get_edid+0xe9/0x3d0 [drm] [ 7.207137] ? drm_get_edid+0xe9/0x3d0 [drm] [ 7.207161] ? intel_gmbus_get_adapter+0x45/0x50 [i915] [ 7.207183] intel_hdmi_set_edid+0x4a/0x1c0 [i915] [ 7.207204] intel_hdmi_detect+0x8d/0xb0 [i915] [ 7.207209] drm_helper_probe_detect+0x75/0xa0 [drm_kms_helper] [ 7.207213] drm_helper_probe_single_connector_modes+0xee/0x730 [drm_kms_helper] [ 7.207218] drm_setup_crtcs+0x139/0x9e0 [drm_kms_helper] [ 7.207222] __drm_fb_helper_initial_config_and_unlock+0x3f/0x3b0 [drm_kms_helper] [ 7.207225] ? __switch_to+0x1f3/0x4d0 [ 7.207229] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] [ 7.207253] intel_fbdev_initial_config+0x18/0x30 [i915] [ 7.207255] async_run_entry_fn+0x36/0x150 [ 7.207258] process_one_work+0x156/0x3f0 [ 7.207260] worker_thread+0x4b/0x460 [ 7.207262] kthread+0x109/0x140 [ 7.207263] ? process_one_work+0x3f0/0x3f0 [ 7.207265] ? kthread_create_on_node+0x70/0x70 [ 7.207267] ret_from_fork+0x25/0x30 [ 7.207269] Code: fb ff ff 89 c2 eb d8 45 31 ff e9 f9 fc ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 <48> 8b 47 10 48 89 fb 48 83 38 00 74 6a 65 8b 05 5e 66 ea 44 a9 [ 7.207291] RIP: i2c_transfer+0xe/0xc0 RSP: ffffad6ec3acfa78 [ 7.207292] CR2: 0000000000000010 [ 7.207294] ---[ end trace 694c65d4d242db89 ]---
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.