Bug 1893717

Summary:

External HDMI display unreliable with Lenovo P1 Gen 2 and Intel 630 Graphics

Product:

[Fedora] Fedora

Reporter:

Bryn M. Reeves <bmr>

Component:

kernel

Assignee:

Lyude <lyude>

Status:

NEW ---

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

high

Docs Contact:

Priority:

high

Version:

CC:

acancell, acaringi, aelgendy, airlied, akrejcir, almartin, anprice, bcygan, bskeggs, bward, cmaiolin, daxelrod, dgupte, djuran, drjones, dsanzmor, ecurtin, eelena, fmarquez, gsmet, hdegoede, hgomes, hmlnarik, imre.deak, itamar, jarodwilson, jbainbri, jbeitia, jeremy, jglisse, jkolarik, jonathan, josef, kernel-maint, lgoncalv, linville, lyude, malmond, masami256, mavazque, mchehab, me, mjg59, mkolman, mperina, mramendi, mveber, ncarboni, ndegraef, pgarciaq, rareddy, rlinden, rpelisse, rsandu, sgehwolf, sizucchi, steved, tasleson, tbecker, tsorense, tweining

Target Milestone:

---

Keywords:

Reopened

Target Release:

---

Flags:

tbecker: needinfo-
fmarquez: needinfo? (lyude)

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2021-11-30 16:11:25 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
dmesg from an affected boot with drm.debug=0x116	none
Photograph of screen with messages when the rawhide kernel (5.12.0-0.rc1.162.fc35.x86_64) does not boot	none
log from dpms off ... dpms on by: journalctl --since '2021-11-12 18:20'	none
HP LP2465 QuickSpecs	none
dmesg with additional debug logging	none

Description Bryn M. Reeves 2020-11-02 12:42:17 UTC

1. Please describe the problem:
I have a Lenovo P1 Gen2 laptop with an Intel UHD Graphics 630 adapter:

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Mobile) (rev 02)

This is the basic model without any NVidia GPU. The laptop has a single physical HDMI port on the main chassis (no docking station).

Using an external monitor (a Samsung LU28R55) attached to the HDMI port is unreliable: frequently the screen fails to come up and is reported as "Unknown Monitor". This sometimes happens on start up - other times it happens when waking the screen up. The logs contain errors relating to Link Training and EDID is not available:

Oct 26 11:48:17 localhost.localdomain kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
Oct 26 11:48:17 localhost.localdomain kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful

Oct 26 11:48:26 localhost.localdomain colord[1276]: failed to get edid data: EDID length is too small
Oct 26 11:48:34 localhost.localdomain gsd-color[1806]: failed to get edid: unable to get EDID for output
Oct 26 11:48:34 localhost.localdomain gsd-color[1806]: unable to get EDID for xrandr-DP-1: unable to get EDID for output

There are also a few kernel warnings coming from edid code.

Following some similar reports on freedesktop.org it was suggested to try i915.disable_power_well=0. With this setting the system is more usable but the external display occasionally still stops working with similar errors in the log. This most often happens when waking up the display after locking the screen.

2. What is the Version-Release number of the kernel:
5.8.16-200.fc32.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Unknown - new hardware (although similar ABRT reports in bugzilla cover f31/32/33beta).

4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:

Yes:

1. Disable any workarounds/module options
2. Boot the system and attach the HDMI connector.
3. Lock the screen, let the screen power off, then attempt to unlock.
4. Screen remains blank. Eventually times out and fails back to the laptop.

Sometimes the problem is already apparent at 2 when the display is first attached. Other times it works for a while and fails on unlock.

5. Does this problem occur with the latest Rawhide kernel? To install the
Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
``sudo dnf update --enablerepo=rawhide kernel``:

Yes. Tested with 5.10.0-0.rc0.20201021git071a0578b0ce.49.fc34. Similar behaviour and errors in the log.

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.

I spoke with Lyude on IRC and will attach an sosreport with drm debug logs in a subsequent comment.

I am now using a Thunderbolt-DisplayPort dongle as a workaround: this has been running stably for a few days now and there are no drm or EDID errors reported in the logs.

Comment 1 Bryn M. Reeves 2020-11-02 12:49:06 UTC

Created attachment 1725789 [details]
dmesg from an affected boot with drm.debug=0x116

Comment 2 Bryn M. Reeves 2020-11-02 12:57:19 UTC

Typical warning seen with 5.8.16-200.fc32.x86_64 and external HDMI display connected:

Oct 25 15:39:14 localhost.localdomain kernel: [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
Oct 25 15:39:14 localhost.localdomain kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
Oct 25 15:39:14 localhost.localdomain kernel: [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
Oct 25 15:39:14 localhost.localdomain kernel: [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
Oct 25 15:39:14 localhost.localdomain kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON init failed on port B
Oct 25 15:39:14 localhost.localdomain kernel: [drm] Initialized i915 1.6.0 20200515 for 0000:00:02.0 on minor 0
Oct 25 15:39:14 localhost.localdomain kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Oct 25 15:39:14 localhost.localdomain kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
Oct 25 15:39:14 localhost.localdomain kernel: ------------[ cut here ]------------
Oct 25 15:39:14 localhost.localdomain kernel: WARNING: CPU: 11 PID: 113 at kernel/kmod.c:137 __request_module+0x22d/0x3af
Oct 25 15:39:14 localhost.localdomain kernel: Modules linked in: i915 i2c_algo_bit drm_kms_helper sdhci_pci crct10dif_pclmul cec crc32_pclmul cqhci crc32c_intel sdhci drm e1000e ghash_clmul>
Oct 25 15:39:14 localhost.localdomain kernel: CPU: 11 PID: 113 Comm: kworker/u24:1 Not tainted 5.8.16-200.fc32.x86_64 #1
Oct 25 15:39:14 localhost.localdomain kernel: Hardware name: LENOVO 20QUS10L04/20QUS10L04, BIOS N2OET42W (1.29 ) 01/20/2020
Oct 25 15:39:14 localhost.localdomain kernel: Workqueue: events_unbound async_run_entry_fn
Oct 25 15:39:14 localhost.localdomain kernel: RIP: 0010:__request_module+0x22d/0x3af
Oct 25 15:39:14 localhost.localdomain kernel: Code: 44 89 ea 48 8d b5 68 ff ff ff e8 9e 94 cf 00 49 8b 04 24 48 85 c0 75 dc e9 b5 fe ff ff e8 6b ea ff ff 84 c0 0f 84 20 fe ff ff <0f> 0b e9 >
Oct 25 15:39:14 localhost.localdomain kernel: RSP: 0018:ffffab81413af9b8 EFLAGS: 00010202
Oct 25 15:39:14 localhost.localdomain kernel: RAX: ffff9aa91806d901 RBX: 0000000000000001 RCX: 0000000000000000
Oct 25 15:39:14 localhost.localdomain kernel: RDX: ffffffffc073cad3 RSI: ffffffff9f44435e RDI: ffff9aa9175ace80
Oct 25 15:39:14 localhost.localdomain kernel: RBP: ffffab81413afa90 R08: ffff9aa917d24c6b R09: 0000000000000000
Oct 25 15:39:14 localhost.localdomain kernel: R10: ffffab81413afaa0 R11: ffff9aa917d24c6b R12: ffffffff9f44435e
Oct 25 15:39:14 localhost.localdomain kernel: R13: ffffab81413afaa0 R14: ffff9aa9182d7800 R15: ffff9aa90fce6660
Oct 25 15:39:14 localhost.localdomain kernel: FS:  0000000000000000(0000) GS:ffff9aa91c4c0000(0000) knlGS:0000000000000000
Oct 25 15:39:14 localhost.localdomain kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 25 15:39:14 localhost.localdomain kernel: CR2: 0000564b6b9d6140 CR3: 000000080ff9e004 CR4: 00000000003606e0
Oct 25 15:39:14 localhost.localdomain kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 25 15:39:14 localhost.localdomain kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Oct 25 15:39:14 localhost.localdomain kernel: Call Trace:
Oct 25 15:39:14 localhost.localdomain kernel:  ? kvasprintf+0x6d/0xa0
Oct 25 15:39:14 localhost.localdomain kernel:  ? kobject_set_name_vargs+0x6f/0x90
Oct 25 15:39:14 localhost.localdomain kernel:  rc_map_get+0x30/0x60
Oct 25 15:39:14 localhost.localdomain kernel:  rc_register_device+0x108/0x510
Oct 25 15:39:14 localhost.localdomain kernel:  cec_register_adapter+0x5c/0x280 [cec]
Oct 25 15:39:14 localhost.localdomain kernel:  drm_dp_cec_set_edid+0x11e/0x178 [drm_kms_helper]
Oct 25 15:39:14 localhost.localdomain kernel:  intel_dp_set_edid+0x8d/0xc0 [i915]
Oct 25 15:39:14 localhost.localdomain kernel:  intel_dp_detect+0x188/0x5c0 [i915]
Oct 25 15:39:14 localhost.localdomain kernel:  drm_helper_probe_single_connector_modes+0xc2/0x6d0 [drm_kms_helper]
Oct 25 15:39:14 localhost.localdomain kernel:  drm_client_modeset_probe+0x25b/0x1320 [drm]
Oct 25 15:39:14 localhost.localdomain kernel:  __drm_fb_helper_initial_config_and_unlock+0x37/0x470 [drm_kms_helper]
Oct 25 15:39:14 localhost.localdomain kernel:  ? _cond_resched+0x16/0x40
Oct 25 15:39:14 localhost.localdomain kernel:  intel_fbdev_initial_config+0x14/0x30 [i915]
Oct 25 15:39:14 localhost.localdomain kernel:  async_run_entry_fn+0x39/0x160
Oct 25 15:39:14 localhost.localdomain kernel:  process_one_work+0x1b4/0x370
Oct 25 15:39:14 localhost.localdomain kernel:  worker_thread+0x53/0x3e0
Oct 25 15:39:14 localhost.localdomain kernel:  ? process_one_work+0x370/0x370
Oct 25 15:39:14 localhost.localdomain kernel:  kthread+0x11b/0x140
Oct 25 15:39:14 localhost.localdomain kernel:  ? __kthread_bind_mask+0x60/0x60
Oct 25 15:39:14 localhost.localdomain kernel:  ret_from_fork+0x1f/0x30
Oct 25 15:39:14 localhost.localdomain kernel: ---[ end trace 36f05baa67c71c59 ]---

Comment 3 Bryn M. Reeves 2020-11-02 12:58:46 UTC

These warnings did not appear when booting the system with drm.debug=0x116 (although the problem still occurs).

Comment 5 Arthur Ferreira 2021-01-08 18:18:19 UTC

Same thing happening with me, but not only when the screen is locked. It's just a black screen and sometimes the monitor isn't identified at all.

And I'm getting the same error on dmseg:

~~~
[    2.033141] Call Trace:
[    2.033145]  ? kvasprintf+0x6d/0xa0
[    2.033147]  ? kobject_set_name_vargs+0x6f/0x90
[    2.033149]  rc_map_get+0x30/0x60
[    2.033150]  rc_register_device+0x108/0x510
[    2.033152]  cec_register_adapter+0x5c/0x280 [cec]
[    2.033159]  drm_dp_cec_set_edid+0x11e/0x178 [drm_kms_helper]
[    2.033196]  intel_dp_set_edid+0x8d/0xc0 [i915]
[    2.033226]  intel_dp_detect+0x185/0x5e0 [i915]
[    2.033232]  drm_helper_probe_single_connector_modes+0xc2/0x6d0 [drm_kms_helper]
[    2.033244]  drm_client_modeset_probe+0x25b/0x1320 [drm]
[    2.033247]  ? __switch_to_asm+0x40/0x70
[    2.033247]  ? __switch_to_asm+0x34/0x70
[    2.033248]  ? __switch_to_asm+0x40/0x70
[    2.033249]  ? __switch_to_asm+0x34/0x70
[    2.033250]  ? __switch_to_asm+0x40/0x70
[    2.033251]  ? __switch_to_asm+0x34/0x70
[    2.033252]  ? __switch_to_asm+0x40/0x70
[    2.033252]  ? __switch_to_asm+0x34/0x70
[    2.033253]  ? __switch_to_asm+0x40/0x70
[    2.033254]  ? __switch_to_asm+0x34/0x70
[    2.033255]  ? __switch_to_asm+0x40/0x70
[    2.033256]  ? __switch_to_asm+0x34/0x70
[    2.033256]  ? __switch_to_asm+0x40/0x70
[    2.033257]  ? __switch_to_asm+0x34/0x70
[    2.033261]  __drm_fb_helper_initial_config_and_unlock+0x37/0x470 [drm_kms_helper]
[    2.033263]  ? __switch_to_asm+0x34/0x70
[    2.033263]  ? __switch_to_asm+0x40/0x70
[    2.033264]  ? __switch_to_asm+0x34/0x70
[    2.033265]  ? __switch_to_asm+0x40/0x70
[    2.033266]  ? __switch_to_asm+0x34/0x70
[    2.033267]  ? _cond_resched+0x16/0x40
[    2.033296]  intel_fbdev_initial_config+0x14/0x30 [i915]
[    2.033297]  async_run_entry_fn+0x39/0x160
[    2.033298]  process_one_work+0x1b4/0x380
[    2.033299]  worker_thread+0x53/0x3e0
[    2.033300]  ? process_one_work+0x380/0x380
[    2.033301]  kthread+0x115/0x140
[    2.033302]  ? __kthread_bind_mask+0x60/0x60
[    2.033303]  ret_from_fork+0x1f/0x40
[    2.033304] ---[ end trace a131c1ed62542f12 ]---
~~~

Same problems using HDMI through Lenovo dock using Thunderbolt.

Comment 6 Bryn M. Reeves 2021-01-11 15:49:08 UTC

Locking the screen isn't necessary - I just found it to trigger it quite reliably in my testing.

Comment 7 Misha Ramendik 2021-03-01 19:10:31 UTC

I am having the same issue on Fedora 33, Lenovo P1 Gen3, i915 driver. And dmesg has a lot of error messages like this:

[29237.498886] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[29247.681037] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[29247.922338] [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
[29247.922461] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[29247.922571] [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
[29247.929806] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[29265.430791] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[29265.435448] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[29272.308855] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[29272.313634] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful

Comment 8 Misha Ramendik 2021-03-04 02:24:09 UTC

Error now triggered when I disconnected the monitor. The system was dettecting a "phantm" monitor on this port with a 1024x768 max resolution. When I reconnectred the monitor it did not turn on, while the max 1024x768 continued to be detected. The dmesg log had the same error messages about link training and LPSCON.

Took two cold boots to snap back to normal.

Comment 9 Lyude 2021-03-04 18:17:51 UTC

Hi! Thank you for poking me about this, I meant to take a look but it slipped my mind. Could you try the kernel at https://fedoraproject.org/wiki/RawhideKernelNodebug and let me know if that fixes your issue? Would be good to know as it'll tell us if someone upstream has already fixed this issue or not

Comment 10 Misha Ramendik 2021-03-05 00:12:53 UTC

Hi Lyude!

I have installed the rawhide kernel as described in the suggested link and found that it sometimes fails to complete the boot. I don't know how to create and retrieve permanent boot logs under systemd, but I do know how to remove "rhgb quiet" from the kernel parameters, so I did that and photographed the screen when it does not boot. I will attach the photo, it appears to be this same type of messages - so if anything it became worse?

When it did boot, I was also able to reproduce the original issue. A few sleeps/wake-ups did not do it, but then I tried unplugging the HDMI connector and plugging it back in, and after the second try the problem happened, dmesg:

[  139.246030] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  139.487240] [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
[  139.487304] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  139.487537] [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
[  139.898698] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  140.138946] [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
[  140.139010] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  140.139241] [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
[  141.512167] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  141.751526] [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
[  141.751584] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  141.751794] [drm:intel_dp_set_power [i915]] *ERROR* LSPCON resume failed
[  142.153780] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled

Comment 11 Misha Ramendik 2021-03-05 00:14:35 UTC

Created attachment 1760782 [details]
Photograph of screen with messages when the rawhide kernel (5.12.0-0.rc1.162.fc35.x86_64) does not boot

Comment 12 Misha Ramendik 2021-03-08 17:46:52 UTC

Possibly related: https://gitlab.freedesktop.org/drm/intel/-/issues/2145

Comment 13 Imre Deak 2021-03-31 17:51:24 UTC

Did this HDMI/LSPCON port work on earlier kernel versions? Is there an HDMI firmware upgrade for the failing platforms?

Comment 14 Lyude 2021-03-31 17:52:39 UTC

(In reply to Imre Deak from comment #13)
> Did this HDMI/LSPCON port work on earlier kernel versions? Is there an HDMI
> firmware upgrade for the failing platforms?

(jfyi - imre is someone from Intel I asked to look at this, if there aren't any updates available I will talk to my contacts at Lenovo to see if there's some way we can update this)

Comment 15 Thiago Rafael Becker 2021-03-31 18:03:29 UTC

Hi Imre,

I'm currently running my Lenovo P1 Gen 2 with an upstream kernel compiled from git id 28806e4d9b97865b450d72156e9ad229f2067f0b. Several things improved from what is described in this bug:
  - suspending the system restores the access to the second monitor.
  - closing the lid (without suspending) moves all applications to the external monitor

From my testing, locking the screen still presents the same behavior of not restoring the external monitor after coming back from the locked screen.

Please let me know if you need any information.

Best,
Thiago

Comment 16 Lyude 2021-03-31 18:09:07 UTC

(In reply to Thiago Rafael Becker from comment #15)
> Hi Imre,
> 
> I'm currently running my Lenovo P1 Gen 2 with an upstream kernel compiled
> from git id 28806e4d9b97865b450d72156e9ad229f2067f0b. Several things
> improved from what is described in this bug:
>   - suspending the system restores the access to the second monitor.
>   - closing the lid (without suspending) moves all applications to the
> external monitor
> 
> From my testing, locking the screen still presents the same behavior of not
> restoring the external monitor after coming back from the locked screen.
> 
> Please let me know if you need any information.
> 
> Best,
> Thiago

We need someone to see if there are HDMI related firmware updates available and if so whether or not those fix the issues described here

Comment 17 Imre Deak 2021-03-31 18:33:01 UTC

Is the 0x4b0 AUX write related to the fwupdmgr? Could it be disabled somehow so this write doesn't happen and see if the problem can be still reproduced?

Comment 18 Lyude 2021-03-31 19:05:13 UTC

(In reply to Imre Deak from comment #17)
> Is the 0x4b0 AUX write related to the fwupdmgr? Could it be disabled somehow
> so this write doesn't happen and see if the problem can be still reproduced?

(to clarify - it is related to fwupdmgr)
misha/bryn (I assume you meant to poke them, since thiago just jumped onto this bug and hasn't provided any of the logs here) - they're asking if you could try disabling fwupdmgr (make sure it's disabled as well) and see if that changes anything

Comment 19 Bryn M. Reeves 2021-04-01 09:26:49 UTC

I updated all the laptop firmware to the latest versions available on LVFS/fwupd and Lenovo's site before filing this bug, although I have not checked back for any new updates since I filed this bug. I've not had any fwupd notifications either but I'll check today to see if anything new is available.

Comment 20 Lyude 2021-04-27 18:45:53 UTC

(In reply to Bryn M. Reeves from comment #19)
> I updated all the laptop firmware to the latest versions available on
> LVFS/fwupd and Lenovo's site before filing this bug, although I have not
> checked back for any new updates since I filed this bug. I've not had any
> fwupd notifications either but I'll check today to see if anything new is
> available.

Any updates on this?

Comment 21 Bryn M. Reeves 2021-04-28 14:19:03 UTC

I checked fwupd this morning and there were updates available for the system firmware, Intel management engine & the Samsung SSD. I've applied those but I'll need to swap the cables over to re-test the HDMI monitor connection. I'll try to get that done later today (leaving NEEDINFO set for now).

Updates applied 28/4:

├─Intel Management Engine:
│ │   Device ID:          35300bd326f97a09c746551d9a4bd25d3d1ede27
│ │   Previous version:   192.47.1524
│ │   Update State:       Success
│ │   Last modified:      2021-04-28 08:39
│ │   GUID:               993f4478-ab74-48e2-bf65-26e6462e01d6
│ │   Device Flags:       • Internal device
│ │                       • Updatable
│ │                       • System requires external power source
│ │                       • Supported on remote server
│ │                       • Needs a reboot after installation
│ │                       • Device is usable for the duration of the update
│ │ 
│ └─ThinkPad P1 Gen2 X1 Extreme 2nd  Corporate ME Update:
│       New version:      192.72.1757
│       Remote ID:        lvfs
│       Summary:          Lenovo ThinkPad P1 Gen2 X1 Extreme 2nd Corporate ME Firmware
│       Licence:          Proprietary
│       Size:             12.2 MB
│       Created:          2016-07-08
│       Urgency:          High
│       Details:          https://pcsupport.lenovo.com/de/en/search?query=N2ORM15W
│       Vendor:           Lenovo Ltd.
│       Description:      
│       Lenovo ThinkPad P1 Gen2 X1 Extreme 2nd Corporate ME Firmware Version 12.0.72.1757 (LVFS: 192.72.1757)
│     
├─System Firmware:
│ │   Device ID:          105dc4287111ca23352a3b4759a602c10ad8bf88
│ │   Previous version:   0.1.34
│ │   Update State:       Success
│ │   Last modified:      2021-04-28 08:47
│ │   GUID:               55d04ffc-714a-4457-b982-d244343e1958
│ │   Device Flags:       • Internal device
│ │                       • Updatable
│ │                       • System requires external power source
│ │                       • Supported on remote server
│ │                       • Needs a reboot after installation
│ │                       • Cryptographic hash verification is available
│ │                       • Device is usable for the duration of the update
│ │ 
│ └─ThinkPad P1 Gen 2/X1 Extreme 2nd (W-BIOS for Machine types: 20QT, 20QU, 20QV, 20QW) System Update:
│       New version:      0.1.38
│       Remote ID:        lvfs
│       Summary:          Lenovo ThinkPad P1 Gen 2/X1 Extreme 2nd System Firmware
│       Licence:          Proprietary
│       Size:             25.0 MB
│       Created:          2021-02-18
│       Urgency:          High
│       Vendor:           Lenovo Ltd.
│       Description:      
│       Lenovo ThinkPad P1 Gen 2/X1 Extreme 2nd System Firmware 1.38
│       
│       The computer will be restarted automatically after updating BIOS completely.
│       
│       Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│     
└─SAMSUNG MZVLB512HBJQ-000L7:
  │   Device ID:          03281da317dccd2b18de2bd1cc70a782df40ed7e
  │   Previous version:   4M2QEXF7
  │   Update State:       Success
  │   Last modified:      2021-04-28 08:47
  │   GUID:               0b4d773a-7ac3-58c1-a541-e22ef1cdfe02
  │   Device Flags:       • Internal device
  │                       • Updatable
  │                       • System requires external power source
  │                       • Supported on remote server
  │                       • Needs a reboot after installation
  │                       • Device is usable for the duration of the update
  │ 
  └─PM981a Device Update:
        New version:      5M2QEXF7
        Remote ID:        lvfs
        Summary:          Do NOT turn off your computer or remove the AC adapter while update is in progress The computer shall be restarted after updating firmware completely. The device may not properly function until you shut down or reboot PC *Supported devices and firmware version : SAMSUNG MZVLB512HBJQ-000L7 / 00AL7, SAMSUNG MZVLB1T0HBLR-000L7 / 00AL7 and 4M2QEXF7 *Supported Product Scope : Lenovo ThinkPad, ThinkCentre , ThinkStation , IdeaCentre
        Licence:          Proprietary
        Size:             1.3 MB
        Created:          2016-07-08
        Urgency:          High
        Vendor:           SAMSUNG CO. LTD
        Description:      
        Do NOT turn off your computer or remove the AC adapter while update is in progress
        
        The computer shall be restarted after updating firmware completely. The device may not properly function until you shut down or reboot PC
        
        *Supported devices and firmware version : SAMSUNG MZVLB512HBJQ-000L7 / 00AL7, SAMSUNG MZVLB1T0HBLR-000L7 / 00AL7 and 4M2QEXF7
        
        *Supported Product Scope : Lenovo ThinkPad, ThinkCentre , ThinkStation , IdeaCentre

Comment 22 Hynek Mlnarik 2021-08-05 09:34:18 UTC

I am encountering same issue with Lenovo P1 Gen 3 on Fedora 34

$ journalctl -r
[...]
srp 05 11:29:58 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
srp 05 11:29:58 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
srp 05 11:29:58 fedora kernel: [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
srp 05 11:29:57 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
srp 05 11:29:56 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
srp 05 11:29:56 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
srp 05 11:29:56 fedora kernel: [drm:drm_lspcon_set_mode [drm_kms_helper]] *ERROR* LSPCON mode change timed out
srp 05 11:29:56 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled

All updates, be it firmware or F34, have been applied.

Comment 23 Ben Cotton 2021-11-04 13:49:00 UTC

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 24 Ben Cotton 2021-11-04 14:18:23 UTC

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 25 Ben Cotton 2021-11-04 15:16:06 UTC

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Marek Veber 2021-11-12 17:37:34 UTC

(In reply to Hynek Mlnarik from comment #22)
> I am encountering same issue with Lenovo P1 Gen 3 on Fedora 34
> 
> $ journalctl -r
> [...]
> srp 05 11:29:58 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON
> resume failed
> srp 05 11:29:58 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]]
> *ERROR* LSPCON mode change failed
> srp 05 11:29:58 fedora kernel: [drm:drm_lspcon_set_mode [drm_kms_helper]]
> *ERROR* LSPCON mode change timed out
> srp 05 11:29:57 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON
> mode hasn't settled
> srp 05 11:29:56 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON
> resume failed
> srp 05 11:29:56 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]]
> *ERROR* LSPCON mode change failed
> srp 05 11:29:56 fedora kernel: [drm:drm_lspcon_set_mode [drm_kms_helper]]
> *ERROR* LSPCON mode change timed out
> srp 05 11:29:56 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON
> mode hasn't settled
> 
> All updates, be it firmware or F34, have been applied.

Same messages in logfile with my F35 (and F34 before upgrade).

The monitor goes to small very resolution after my "dpms off" (while coffee break) and after unplugging DVI cable xrand shows remains displayed DP-1 output.
Suspend into ram and wake up enables the correct xrand output: "DP-1 disconnected" and after plunging cable monitor works.


correct xrand output (while monitor is working):
==============================================
[mveber@fedora service]$ xrandr 
Screen 0: minimum 320 x 200, current 3840 x 3240, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+0+2160 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080     60.00*+  59.97    59.96    59.93    48.00  
   1680x1050     59.95    59.88  
   1400x1050     59.98  
   1600x900      59.99    59.94    59.95    59.82  
   1280x1024     60.02  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1280x800      59.99    59.97    59.81    59.91  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
DP-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 697mm x 392mm
   3840x2160     60.00 +  50.00    59.94    30.00    25.00    24.00    29.97    23.98* 
   2560x1440     59.95  
   1920x1080     60.00    50.00    59.94    30.00    24.00    29.97    23.98    60.00  
   1680x1050     59.88  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-3-1 disconnected (normal left inverted right x axis y axis)
DP-3-2 disconnected (normal left inverted right x axis y axis)
DP-3-3 disconnected (normal left inverted right x axis y axis)
==============================================

bad xrand output (the same while monitor will be unplugged DP-1 goes to 1024x768) ofter dpms off:
==============================================
mveber@fedora service]$ xset dpms force suspend ;sleep 3;xset dpms force on
[mveber@fedora service]$ xrandr 
Screen 0: minimum 320 x 200, current 1920 x 1848, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080     60.00*+  59.97    59.96    59.93    48.00  
   1680x1050     59.95    59.88  
   1400x1050     59.98  
   1600x900      59.99    59.94    59.95    59.82  
   1280x1024     60.02  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1280x800      59.99    59.97    59.81    59.91  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
DP-1 connected 1024x768+896+1080 (normal left inverted right x axis y axis) 697mm x 392mm
   1024x768      60.00* 
   800x600       60.32    56.25  
   848x480       60.00  
   640x480       59.94  
   1920x1080     60.00  
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-3-1 disconnected (normal left inverted right x axis y axis)
DP-3-2 disconnected (normal left inverted right x axis y axis)
DP-3-3 disconnected (normal left inverted right x axis y axis)
==============================================

I have a full log from the time (part of it is here): 
...
lis 12 18:22:25 fedora slack.desktop[1101022]: [11/12/21, 18:22:25:196] info: Store: UPDATE_SETTINGS {
lis 12 18:22:25 fedora slack.desktop[1101022]:   "mainWindowSettings": {
lis 12 18:22:25 fedora slack.desktop[1101022]:     "fullScreen": false,
lis 12 18:22:25 fedora slack.desktop[1101022]:     "maximized": true,
lis 12 18:22:25 fedora slack.desktop[1101022]:     "bounds": {
lis 12 18:22:25 fedora slack.desktop[1101022]:       "width": 1024,
lis 12 18:22:25 fedora slack.desktop[1101022]:       "height": 768,
lis 12 18:22:25 fedora slack.desktop[1101022]:       "x": 896,
lis 12 18:22:25 fedora slack.desktop[1101022]:       "y": 1080
lis 12 18:22:25 fedora slack.desktop[1101022]:     }
lis 12 18:22:25 fedora slack.desktop[1101022]:   }
lis 12 18:22:25 fedora slack.desktop[1101022]: }
lis 12 18:22:25 fedora slack.desktop[1101022]: [11/12/21, 18:22:25:199] info: [DESKTOP-SIDE-EFFECT] Update from desktop for keys  ["settings"]
lis 12 18:22:25 fedora slack.desktop[1101022]: [11/12/21, 18:22:25:890] info: [RTM] (T027F3GAJ) Processed 1 dnd_updated_user event(s) over 0.50ms
lis 12 18:22:41 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
lis 12 18:22:42 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
lis 12 18:22:42 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
lis 12 18:22:42 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
lis 12 18:22:42 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): EDID vendor "SAM", prod id 3922
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Using hsync ranges from config file
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Using vrefresh ranges from config file
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Printing DDC gathered Modelines:
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "3840x2160"x0.0  594.00  3840 4016 4104 4400  2160 2168 2178 2250 +hsync +vsync (135.0 kHz eP)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "3840x2160"x0.0  297.00  3840 4016 4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  576 581 586 625 -hsync -vsync (31.2 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1920x1080"x0.0   74.25  1920 2558 2602 2750  1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1920x1080"x0.0   74.25  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (33.8 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1280x800"x0.0   71.00  1280 1328 1360 1440  800 803 809 823 +hsync -vsync (49.3 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1440x900"x0.0   88.75  1440 1488 1520 1600  900 903 909 926 +hsync -vsync (55.5 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1600x900"x60.0  119.00  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (II) modeset(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
lis 12 18:22:42 fedora /usr/libexec/gdm-x-session[2411]: (--) modeset(0): HDMI max TMDS frequency 300000KHz
lis 12 18:23:44 fedora slack.desktop[1101022]: [11/12/21, 18:23:44:260] info: [DND] (T027F3GAJ) Checking for changes in DND status for the following members: U02L1L0HTD0,UTK9BMR8X
lis 12 18:23:44 fedora slack.desktop[1101022]: [11/12/21, 18:23:44:266] info: [DND] (T027F3GAJ) Will check for changes in DND status again in 5 minutes
lis 12 18:23:51 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
lis 12 18:23:51 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
lis 12 18:23:51 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
lis 12 18:23:51 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
lis 12 18:23:51 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
lis 12 18:23:51 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
lis 12 18:23:53 fedora kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
lis 12 18:23:53 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
lis 12 18:23:53 fedora kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
lis 12 18:23:53 fedora kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
lis 12 18:23:53 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
lis 12 18:23:53 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
...

Comment 27 Marek Veber 2021-11-12 17:44:19 UTC

Created attachment 1841478 [details]
log from dpms off ... dpms on by: journalctl --since '2021-11-12 18:20'

Comment 28 Lyude 2021-11-12 19:34:04 UTC

Hi - I should probably let y'all know I've actually been looking at this issue, and you can follow the status of it at:

https://gitlab.freedesktop.org/drm/intel/-/issues/4516

Currently talking with Lenovo as well to have them take a look at this, as I believe it may very well be an issue with the LSPCON firmware

Comment 29 Ben Cotton 2021-11-30 16:11:25 UTC

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 30 Marek Veber 2021-11-30 16:39:35 UTC

I have the same troubles Fedora 35.

Comment 31 Marek Veber 2021-12-01 09:05:28 UTC

In my opinion, the same issue is: https://gitlab.freedesktop.org/drm/intel/-/issues/2145

Comment 32 Marek Veber 2021-12-01 09:32:50 UTC

See this please, isn't is the fix for this issue?
 * https://bbs.archlinux.org/viewtopic.php?pid=1976443#p1976443
 * https://patchwork.freedesktop.org/patch/419758/

Comment 33 Marek Veber 2021-12-01 11:03:34 UTC

(In reply to Marek Veber from comment #32)
> See this please, isn't is the fix for this issue?
>  * https://bbs.archlinux.org/viewtopic.php?pid=1976443#p1976443
>  * https://patchwork.freedesktop.org/patch/419758/

no - this patch is already in my kernel: 5.15.5-200.fc35.x86_64
:(

Comment 34 Lyude 2021-12-01 19:58:39 UTC

I have a feeling this very well might be the same as https://gitlab.freedesktop.org/drm/intel/-/issues/4516 , despite the fact this is the earlier version of the P1 the errors seem to basically be the same. JFYI - I have Lenovo looking at this issue as well, since I'm currently suspicious this is the result of the LSPCON firmware.

Comment 35 Guillaume Smet 2021-12-06 12:27:43 UTC

Exact same issue with a P1 Gen 2 here, with Fedora 35, Kernel 5.15.6 and latest firmwares from Lenovo applied.

Feel free to ask any information you might need, it's not systematic but it happens every other day when I'm lucky.

Comment 36 Lyude 2021-12-07 22:58:42 UTC

(In reply to Guillaume Smet from comment #35)
> Exact same issue with a P1 Gen 2 here, with Fedora 35, Kernel 5.15.6 and
> latest firmwares from Lenovo applied.
> 
> Feel free to ask any information you might need, it's not systematic but it
> happens every other day when I'm lucky.

Hey! I'm responding to you but this is for anyone who comes across this bug, I'm trying to work with Lenovo right now but one of the problems we're having is getting this reproduced. If you have any consistent way of reproducing it at will that's the most helpful, but it's also useful for us to know what monitor you're using with your machine and what kind of display configuration you're using.

Comment 37 Guillaume Smet 2021-12-08 08:06:27 UTC

(In reply to Lyude from comment #36)
> Hey! I'm responding to you but this is for anyone who comes across this bug,
> I'm trying to work with Lenovo right now but one of the problems we're
> having is getting this reproduced. If you have any consistent way of
> reproducing it at will that's the most helpful, but it's also useful for us
> to know what monitor you're using with your machine and what kind of display
> configuration you're using.


Hi! So configuration is pretty standard: only one additional attached monitor in HDMI, with the laptop screen kept active. The monitor is directly attached to the laptop, no docks. I don't use suspend, it's just the normal sleep of the monitors when not doing anything.

Usually, I end up with some sort of phantom monitor attached with a resolution of 1024x768 in the Display settings and no signal for the HDMI input of the monitor. Funny thing is that if I use a normal reboot, sometimes the monitor doesn't come back. So it's a full shutdown, wait for 5 seconds then power on again to make sure I get the screen back. I know it's dark magic but that's how it is.

Screen is a brand new Dell S2721DS. Same problem with HDMI1 and HDMI2 entries of the screen.

I can't reproduce it at will but I had the problem nearly every day for a week or two. Strangely, when I just got the monitor, it worked for a few days without issues before going into this issue nearly every day.

Yesterday, I switched to Thunderbolt + Display Port to connect to the screen and I was able to get the monitor back this morning (which didn't happen in days with HDMI). Too early to tell but I'll let you know if I don't encounter the issue in the next few days in this configuration.

Comment 38 Lyude 2021-12-08 22:57:15 UTC

(In reply to Guillaume Smet from comment #37)
> (In reply to Lyude from comment #36)
> > Hey! I'm responding to you but this is for anyone who comes across this bug,
> > I'm trying to work with Lenovo right now but one of the problems we're
> > having is getting this reproduced. If you have any consistent way of
> > reproducing it at will that's the most helpful, but it's also useful for us
> > to know what monitor you're using with your machine and what kind of display
> > configuration you're using.
> 
> 
> Hi! So configuration is pretty standard: only one additional attached
> monitor in HDMI, with the laptop screen kept active. The monitor is directly
> attached to the laptop, no docks. I don't use suspend, it's just the normal
> sleep of the monitors when not doing anything.
> 
> Usually, I end up with some sort of phantom monitor attached with a
> resolution of 1024x768 in the Display settings and no signal for the HDMI
> input of the monitor. Funny thing is that if I use a normal reboot,
> sometimes the monitor doesn't come back. So it's a full shutdown, wait for 5
> seconds then power on again to make sure I get the screen back. I know it's
> dark magic but that's how it is.

Lol. It's unusual but totally not unheard of, I had to deal with a laptop at one point that couldn't reset the GPU properly on warm reboots :P.

> 
> Screen is a brand new Dell S2721DS. Same problem with HDMI1 and HDMI2
> entries of the screen.
> 
> I can't reproduce it at will but I had the problem nearly every day for a
> week or two. Strangely, when I just got the monitor, it worked for a few
> days without issues before going into this issue nearly every day.
> 
> Yesterday, I switched to Thunderbolt + Display Port to connect to the screen
> and I was able to get the monitor back this morning (which didn't happen in
> days with HDMI). Too early to tell but I'll let you know if I don't
> encounter the issue in the next few days in this configuration.

woo! This is definitely useful info. BTW, just to double check can you make sure this is the version of the P1 _without_ the nvidia GPU present? (If it's a CSB laptop you got from Red Hat the answer is yes)

Comment 39 Hynek Mlnarik 2021-12-09 08:26:07 UTC

Maybe this helps - instead of using HDMI port on laptop directly, I started connecting to a HDMI monitor using USB-C to HDMI cable, and I have no issues ever since.  In the office I use Thunderbolt dock with DisplayPort and there are also no issues with monitor reconnect.
It is a CSB P1 laptop.

Comment 40 Guillaume Smet 2021-12-09 09:18:37 UTC

(In reply to Lyude from comment #38)
> woo! This is definitely useful info. BTW, just to double check can you make
> sure this is the version of the P1 _without_ the nvidia GPU present? (If
> it's a CSB laptop you got from Red Hat the answer is yes)

I confirmed it's an Intel GPU - laptop provided by Red Hat IT.

And things definitely look better with Thunderbolt + Display Port: two days without having to shutdown the computer \o/

Comment 41 Marek Veber 2021-12-09 19:24:58 UTC

(In reply to Guillaume Smet from comment #40)
> (In reply to Lyude from comment #38)
> > woo! This is definitely useful info. BTW, just to double check can you make
> > sure this is the version of the P1 _without_ the nvidia GPU present? (If
> > it's a CSB laptop you got from Red Hat the answer is yes)
> 
> I confirmed it's an Intel GPU - laptop provided by Red Hat IT.
> 
> And things definitely look better with Thunderbolt + Display Port: two days
> without having to shutdown the computer \o/

In the case of HDMI on my laptop (Lenovo P1 G3 without nvidia provided by RH too) there is no need to reboot:
1) Unplug the HDMI cable,
2) safe2ram and
3) resume 
... works without reboot ;)

Or disable "display blanking" and replace the behavior with a screensaver :D

The bug can be reproduced (on my laptop) by:
* DPMS->off or
* simple unplugging the HDMI cable

=> then a message about a "connected unknown monitor 1024x768" appears in xrandr output :(
And next connection by HDMI is available after save2ram&resume or reboot only.

Comment 47 Marek Czernek 2022-01-29 09:30:26 UTC

Just to summarize:

1) As of Fedora 35 and Lenovo P1 Gen 3, the issue is still present.

2) There are two workarounds:

2.1) Do not use the HDMI connector; use USB-C to HDMI (thunderbolt) instead. For example, works with a docking station.

2.2) Alternatively, when you plug in your monitor to HDMI and the monitor does not get recognized, it seems like suspending and resuming the laptop helps. Open the terminal and type "systemctl suspend". When you wake your laptop, the monitor should come up.
 
I can confirm the issue on ThinkPad P1 Gen 3, bios N2VET36W (1.21 ), kernel 5.15.16-200.fc35.x86_64.

Comment 48 Robert Sandu 2022-03-16 14:39:37 UTC

Hitting this precise issue, even on 5.16.14-200.fc35.x86_64. 

Yet, the systemctl suspend workaround didn't do the trick in my case and I had to completely shut it down and power back on:

$ journalctl --dmesg --boot=-0 --grep i915 | tail -200
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: enabling device (0006 -> 0007)
mar 16 07:36:09 p1 kernel: fb0: switching to i915 from EFI VGA
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: [drm] [ENCODER:114:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: [drm] [ENCODER:121:DDI D/PHY D] is disabled/in DSI mode with an ungated DDI clock, gate it
mar 16 07:36:09 p1 kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
mar 16 07:36:09 p1 kernel: fbcon: i915drmfb (fb0) is primary device
mar 16 07:36:09 p1 kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
mar 16 07:39:27 p1 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
mar 16 07:39:28 p1 kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
mar 16 14:24:32 p1 kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
mar 16 14:24:32 p1 kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
mar 16 14:24:32 p1 kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
mar 16 14:24:34 p1 kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
mar 16 14:24:34 p1 kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
mar 16 14:24:34 p1 kernel: [drm:intel_dp_detect [i915]] *ERROR* LSPCON resume failed
mar 16 14:24:34 p1 kernel: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
mar 16 14:24:34 p1 kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
mar 16 14:24:34 p1 kernel: [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed

Comment 49 Pau Garcia Quiles 2022-04-07 12:58:26 UTC

Adding to what Marek said in https://bugzilla.redhat.com/show_bug.cgi?id=1893717#c47, I have hit this kind of problems with old monitors that did not support HDCP or some other advanced HDMI feature and what always worked for me was to put one of those cheap HDMI switches from AliExpress in the middle, e. g. https://imgur.com/a/Uqr4RCe

computer ---HDMI---> HDMI switch ---HDMI--->Monitor

Comment 50 Robert Sandu 2022-04-07 14:25:19 UTC

To clarify:

- I've had this [0] issue with a Benq monitor, which supports HDCP v2.2
- As a temporary workaround I've switched to a "Thunderbolt-to-HDMI" adapter: no particular issues with this in the last couple of weeks.  

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1893717#c48

Comment 51 Lyude 2022-04-07 19:35:37 UTC

(In reply to Pau Garcia Quiles from comment #49)
> Adding to what Marek said in
> https://bugzilla.redhat.com/show_bug.cgi?id=1893717#c47, I have hit this
> kind of problems with old monitors that did not support HDCP or some other
> advanced HDMI feature and what always worked for me was to put one of those
> cheap HDMI switches from AliExpress in the middle, e. g.
> https://imgur.com/a/Uqr4RCe
> 
> computer ---HDMI---> HDMI switch ---HDMI--->Monitor

!!! Thank you for posting this, I can't say for sure but to me this is likely going to be very useful for figuring this out - I hadn't even considered something like that might be causing issues.

Could you provide a model + EDID for a display that doesn't work, and one that does?

Comment 52 Lyude 2022-04-07 19:58:34 UTC

(In reply to Lyude from comment #51)
> (In reply to Pau Garcia Quiles from comment #49)
> > Adding to what Marek said in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1893717#c47, I have hit this
> > kind of problems with old monitors that did not support HDCP or some other
> > advanced HDMI feature and what always worked for me was to put one of those
> > cheap HDMI switches from AliExpress in the middle, e. g.
> > https://imgur.com/a/Uqr4RCe
> > 
> > computer ---HDMI---> HDMI switch ---HDMI--->Monitor
> 
> !!! Thank you for posting this, I can't say for sure but to me this is
> likely going to be very useful for figuring this out - I hadn't even
> considered something like that might be causing issues.
> 
> Could you provide a model + EDID for a display that doesn't work, and one
> that does?

Also - I guess dmesg logs from both with

drm.debug=0x116 log_buf_len=50M

Added to your kernel commandline would be super useful, especially if you get a successful modeset with one of the displays - and record the failure of the other in separate logs. (Also, don't trim anything - I very likely need to see the entire kernel log)

Comment 53 Pau Garcia Quiles 2022-04-07 20:55:20 UTC

One that does not work is the HP LP2465, quickspecs attached. I have that monitor in storage so it'll take a few days before I can provided the data you asked for but the Internetz may help:
https://github.com/linuxhw/EDID/blob/master/AnalogDisplay.md?plain=1#L3917
https://github.com/linuxhw/EDID/blob/master/Analog/HP/HWP2675/C5CFEE997748
https://github.com/linuxhw/EDID/blob/master/Analog/HP/HWP2675/64030F5487B9
https://github.com/linuxhw/EDID/blob/master/Analog/HP/HWP2675/86DB8F86D4B9

Here's a bug about this monitor from 13 (!!!) years ago, I don't know if any of the details in there might be useful:
https://bugs.freedesktop.org/show_bug.cgi?id=21632

Important:
1. My laptop is a Lenovo P1 Gen3 (not Gen2) but I suffered from exactly the same problems. Intel integrated graphics. RHEL 8.5 CSB.
2. I used to connect the HP LP2465 to the laptop using an HDMI (laptop-side) to DVI (monitor) adapter. Sometimes graphics would work on first boot but when putting the computer to sleep, monitor would switch off and the only way to get it back was to turn the computer off and on again (don't laugh!). When putting either the Lenovo dock station, or the cheap AliExpress HDMI switch in the middle, problems with the monitor were gone forever.

Please re-add the NEEDINFO if you still want me to provide the dmesg, EDIDs, etc.

Comment 54 Pau Garcia Quiles 2022-04-07 20:57:43 UTC

Created attachment 1871383 [details]
HP LP2465 QuickSpecs

Comment 55 Pau Garcia Quiles 2022-04-07 21:04:28 UTC

BTW, my current monitor, that works flawlessly, is a Samsung LU28R552UQRXEN

Comment 56 ecurtin 2022-04-20 09:24:10 UTC

I hit this issue once every two months. Can take me hours to get my display working once it happens. Still occurring for me on latest kernel fedora 35:

5.16.20-200.fc35.x86_64

Normal when I switch between the physical HDMI and the 4 different branded USB-c powered and unpowered docking stations I have (and try the HDMI ports on those), it eventually works. All the same kind of logs. I'm on xfce and x11 right now...


[  420.978173] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  421.219562] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  421.219571] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  421.219797] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  421.219991] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  421.220178] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  421.228606] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  421.242171] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  422.693164] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  422.934446] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  422.934456] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  422.934715] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  422.934931] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  422.935139] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  422.943674] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  422.959203] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  473.858817] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  474.107168] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  474.107178] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  474.107409] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  474.107603] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  474.107786] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  474.116404] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  474.605807] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  474.852163] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  474.852173] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  474.852400] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  474.852593] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  474.852777] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  474.861385] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  475.335800] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  475.579163] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  475.579172] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  475.579399] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  475.579594] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  475.579787] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  475.588381] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  476.069798] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  476.316156] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  476.316166] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  476.316398] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  476.316591] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  476.316780] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  476.325373] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  478.127793] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  478.371134] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  478.371143] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  478.371376] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  478.371574] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  478.371766] [drm:intel_dp_set_power [i915]] *ERROR* LSPCON init failed on port B
[  478.378090] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  487.387754] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  487.634888] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  487.634899] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  487.635155] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  487.635355] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  487.635549] [drm:intel_dp_detect [i915]] *ERROR* LSPCON init failed on port B
[  487.644001] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  516.101387] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  516.342764] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  516.342766] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  516.342821] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  516.342868] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  516.342912] [drm:intel_dp_set_power [i915]] *ERROR* LSPCON init failed on port B
[  516.348303] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  529.795473] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  530.039843] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  530.039853] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  530.040128] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  530.040345] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  530.040551] [drm:intel_dp_set_power [i915]] *ERROR* LSPCON init failed on port B
[  530.046773] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful
[  540.601046] i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID a8
[  541.015440] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  541.257775] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  541.257784] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  541.258014] [drm:lspcon_init [i915]] *ERROR* LSPCON mode change to PCON failed
[  541.258215] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[  541.258408] [drm:intel_dp_set_power [i915]] *ERROR* LSPCON init failed on port B
[  541.264732] i915 0000:00:02.0: [drm] *ERROR* Link Training Unsuccessful

Comment 57 ecurtin 2022-04-20 09:26:44 UTC

Switching between kernel versions doesn't help once it starts...

Comment 59 Jamie Bainbridge 2022-05-06 03:52:35 UTC

Same issue here. ThinkPad P1 Gen3, BIOS N2VET32W (1.17) 06/24/2021 Running Ubuntu 22.04 with their 5.15.0-27 kernel.

Currently trying v5.17.5 and have added "drm.debug=0x116 log_buf_len=50M" to cmdline. Will report back if I get anything useful.

Thank you for Comment #47 summary with workarounds and Comment #52 with troubleshooting steps, very cool.

Comment 60 Jamie Bainbridge 2022-05-06 07:19:13 UTC

Created attachment 1877518 [details]
dmesg with additional debug logging

(In reply to Lyude from comment #52)
> drm.debug=0x116 log_buf_len=50M

Reproduced with the above by running "xset dpms force off" many times from a fresh boot. First instance of error occurs at:

[  324.774767] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  324.774781] [drm:lspcon_change_mode.constprop.0 [i915]] *ERROR* LSPCON mode change failed
[  324.775116] [drm:lspcon_resume [i915]] *ERROR* LSPCON resume failed
[  325.178557] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled
[  325.669569] [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled

Please needinfo me if I can provide anything else.

Comment 61 Lyude 2022-05-06 19:37:25 UTC

JFYI so everyone knows - there is (finally!) progress being made on this thanks to Lenovo's help, so things are moving forward currently. No ETA yet though

Comment 62 Alfonso Martínez 2022-06-02 15:34:12 UTC

This also happens in Fedora 36.

$uname -a
Linux pc1 5.17.11-300.fc36.x86_64 #1 SMP PREEMPT Wed May 25 15:04:05 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

Hardware: Lenovo ThinkPad P1 Gen3

Comment 66 Lyude 2022-06-27 21:11:56 UTC

Hi everyone! Good news, we finally got some feedback from Lenovo and got some suggestions for i915 that may actually fix this problem. I'm going to try to write up some patches for this and will post them when they're ready for testing (will also fire up a kernel build on koji so people have an RPM to try).

Comment 67 Lyude 2022-06-28 19:51:55 UTC

OK - I wrote up a patch that looks correct to me that's worth giving a shot: 

https://koji.fedoraproject.org/koji/taskinfo?taskID=88854412

F35 build also available upon request

Keep in mind I haven't tested this on any real machines yet as unfortunately I don't have access to any laptops that can reproduce this, so hopefully I didn't make any silly mistakes with this.

Comment 68 Lyude 2022-06-28 20:10:16 UTC

ALSO - I realized in the description of the solution for this issue that we got from the OEM, it wasn't entirely clear whether we should be applying this fix in response to a short DisplayPort hotplug pulse or a long pulse (yes-we're still talking about the HDMI port here I promise). It's proooobably a short pulse, but in case I guessed wrong and the build above this comment doesn't fix the problem then you can also try this build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=88855943

Definitely try the 88854412 build first though

Comment 69 Lyude 2022-06-28 20:17:04 UTC

Agh, sorry! I messed up the long version of this fix and cancelled that build. Here's the new one, to reiterate:

* Test https://koji.fedoraproject.org/koji/taskinfo?taskID=88854412 first
* If that doesn't fix the problem, try https://koji.fedoraproject.org/koji/taskinfo?taskID=88856394 second

Comment 72 David Sanz 2022-07-01 09:22:27 UTC

Fixed on latest kernel published for fedora 36:

$ uname -a
Linux redhat-laptop 5.18.7-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jun 25 20:06:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux


$ sudo dmesg | grep i915
[    2.141240] i915 0000:00:02.0: enabling device (0006 -> 0007)
[    2.156932] i915 0000:00:02.0: vgaarb: deactivate vga console
[    2.159248] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem
[    2.163421] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    2.235575] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1
[    2.302665] fbcon: i915drmfb (fb0) is primary device
[    2.302678] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[   11.428523] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[   11.695477] sof-audio-pci-intel-cnl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])


$ sudo dmesg | grep LSPCON
$ 


$ sudo dmesg | grep drm
[    0.816462] ACPI: bus type drm_connector registered
[    0.829693] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
[    0.830314] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    2.163421] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    2.235575] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1
[    2.302665] fbcon: i915drmfb (fb0) is primary device
[    2.302678] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[   10.639964] systemd[1]: Starting modprobe - Load Kernel Module drm...

Comment 73 David Sanz 2022-07-01 15:42:38 UTC

On a fresh startup, monitor works, but returning from suspend, errors appears again

Comment 74 Rob Linden 2022-07-04 17:08:31 UTC

I have the same problem on my Thinkpad P1 (Gen3), with Fedora 36, and an external, directly connected HDMI-monitor (iiyama ProLite XUB2493HS, if it matters).

$ uname -a
Linux ufo 5.18.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 2 15:56:43 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

The error, repeating:

$ sudo dmesg | grep i915
[    2.902553] i915 0000:00:02.0: enabling device (0006 -> 0007)
[    2.928433] i915 0000:00:02.0: vgaarb: deactivate vga console
[    2.932494] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem
[    2.935720] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    2.970416] i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
[    2.970421] i915 0000:00:02.0: [drm] [ENCODER:114:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
[    2.970424] i915 0000:00:02.0: [drm] [ENCODER:121:DDI D/PHY D] is disabled/in DSI mode with an ungated DDI clock, gate it
[    3.006453] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1
[    3.071974] fbcon: i915drmfb (fb0) is primary device
[    3.071979] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[   18.925272] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[   19.462519] sof-audio-pci-intel-cnl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 8785.808176] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 8785.808186] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 8785.808190] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 8787.247784] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled


It doesn't _always_ stay off. Today it woke up 2 times after the screen was locked and the monitors were put to sleep. The third time it stayed off.
In order to get it to work again a complete power off of the laptop is required. Just rebooting or unplugging the HDMI or switching off/on the monitor doesn't help.

My "Intel Management Engine" is missing an available firmware-update (225.53.1649), because the update process always fails. The current version is/remains 224.36.1158.

Not sure if relevant: somewhere else it is said that it might actually be sound-related and that the kernel option "snd_hda_codec_hdmi.enable_silent_stream=0" would help. I added that option, it didn't help.

I'd be happy to supply more data/info, if it could help. Should I try this kernel: https://koji.fedoraproject.org/koji/taskinfo?taskID=88854412 ?

Comment 75 Lyude 2022-07-04 19:54:32 UTC

(In reply to David Sanz from comment #73)
> On a fresh startup, monitor works, but returning from suspend, errors
> appears again

Sorry to ask but are you sure that the problem is actually solved? From all of the reports I've seen so far it doesn't seem as if this bug is particularly consistent, and it doesn't always happen on power on but sometimes happens with suspend/resume cycles

Comment 76 Lyude 2022-07-04 20:31:47 UTC

(In reply to Rob Linden from comment #74)
> I have the same problem on my Thinkpad P1 (Gen3), with Fedora 36, and an
> external, directly connected HDMI-monitor (iiyama ProLite XUB2493HS, if it
> matters).
> 
> $ uname -a
> Linux ufo 5.18.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 2 15:56:43
> UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> 
> The error, repeating:
> 
> $ sudo dmesg | grep i915
> [    2.902553] i915 0000:00:02.0: enabling device (0006 -> 0007)
> [    2.928433] i915 0000:00:02.0: vgaarb: deactivate vga console
> [    2.932494] i915 0000:00:02.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=io+mem:owns=mem
> [    2.935720] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> i915/kbl_dmc_ver1_04.bin (v1.4)
> [    2.970416] i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is
> disabled/in DSI mode with an ungated DDI clock, gate it
> [    2.970421] i915 0000:00:02.0: [drm] [ENCODER:114:DDI C/PHY C] is
> disabled/in DSI mode with an ungated DDI clock, gate it
> [    2.970424] i915 0000:00:02.0: [drm] [ENCODER:121:DDI D/PHY D] is
> disabled/in DSI mode with an ungated DDI clock, gate it
> [    3.006453] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> minor 1
> [    3.071974] fbcon: i915drmfb (fb0) is primary device
> [    3.071979] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
> [   18.925272] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04:
> bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
> [   19.462519] sof-audio-pci-intel-cnl 0000:00:1f.3: bound 0000:00:02.0 (ops
> i915_audio_component_bind_ops [i915])
> [ 8785.808176] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
> [ 8785.808186] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
> [ 8785.808190] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
> [ 8787.247784] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
> 
> 
> It doesn't _always_ stay off. Today it woke up 2 times after the screen was
> locked and the monitors were put to sleep. The third time it stayed off.
> In order to get it to work again a complete power off of the laptop is
> required. Just rebooting or unplugging the HDMI or switching off/on the
> monitor doesn't help.
> 
> My "Intel Management Engine" is missing an available firmware-update
> (225.53.1649), because the update process always fails. The current version
> is/remains 224.36.1158.
> 
> Not sure if relevant: somewhere else it is said that it might actually be
> sound-related and that the kernel option
> "snd_hda_codec_hdmi.enable_silent_stream=0" would help. I added that option,
> it didn't help.
> 
> I'd be happy to supply more data/info, if it could help. Should I try this
> kernel: https://koji.fedoraproject.org/koji/taskinfo?taskID=88854412 ?

If you could try both of the kernels in comment #69 (since I'm not totally sure which one of those, if either of them, are actually the correct fix) that would be appreciated!

Comment 78 Rob Linden 2022-07-07 09:29:17 UTC

(In reply to Lyude from comment #76)
> (In reply to Rob Linden from comment #74)
> > I have the same problem on my Thinkpad P1 (Gen3), with Fedora 36, and an
> > external, directly connected HDMI-monitor (iiyama ProLite XUB2493HS, if it
> > matters).
> > 
> > $ uname -a
> > Linux ufo 5.18.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 2 15:56:43
> > UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
>
> If you could try both of the kernels in comment #69 (since I'm not totally
> sure which one of those, if either of them, are actually the correct fix)
> that would be appreciated!

I tried the RPMs from this one: https://koji.fedoraproject.org/koji/taskinfo?taskID=88854446
I installed:
kernel-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
kernel-core-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
kernel-modules-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
kernel-modules-extra-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm

I rebooted.

$ uname -a
Linux ufo 5.18.7-200.LSPCONFixV2.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun 28 19:26:49 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

And then I locked the screen(s) a few times (6x by actively locking it, 1x by waiting for auto-away-lock),
waiting for the external monitor to go to sleep (one time it didn't go to sleep, it stayed awake (but black) and
one time both displays stayed awake, showing the lock screen).

When I logged back in the external monitor came back on! Sometimes it seemed to take a while longer than it's supposed to,
but after waiting a few seconds more it was ok.

When the external monitor wakes up it is making a funny little noise. Like a low squeaky-door noise? Or a tiny woodpecker?
I never noticed that before, so I assume it's new. I hope it's not dangerous for the device.

In dmesg I see a new error:
[  186.476955] i915 0000:00:02.0: [drm] *ERROR* Failed to write the HDMI OEN register to the LSPCON: -5
[  187.585665] i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92

And, still, a few of these, but not as many as before:
[  293.825778] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[  294.067178] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[  294.067181] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[  294.067182] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed

So I'm not sure it's a 100% fix, but so far it looks much better than the regular kernel, thank You!

Comment 79 Lyude 2022-07-07 19:31:41 UTC

(In reply to Rob Linden from comment #78)
> (In reply to Lyude from comment #76)
> > (In reply to Rob Linden from comment #74)
> > > I have the same problem on my Thinkpad P1 (Gen3), with Fedora 36, and an
> > > external, directly connected HDMI-monitor (iiyama ProLite XUB2493HS, if it
> > > matters).
> > > 
> > > $ uname -a
> > > Linux ufo 5.18.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jul 2 15:56:43
> > > UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> >
> > If you could try both of the kernels in comment #69 (since I'm not totally
> > sure which one of those, if either of them, are actually the correct fix)
> > that would be appreciated!
> 
> I tried the RPMs from this one:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=88854446
> I installed:
> kernel-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
> kernel-core-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
> kernel-modules-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
> kernel-modules-extra-5.18.7-200.LSPCONFixV2.fc36.x86_64.rpm
> 
> I rebooted.
> 
> $ uname -a
> Linux ufo 5.18.7-200.LSPCONFixV2.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun
> 28 19:26:49 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> 
> And then I locked the screen(s) a few times (6x by actively locking it, 1x
> by waiting for auto-away-lock),
> waiting for the external monitor to go to sleep (one time it didn't go to
> sleep, it stayed awake (but black) and
> one time both displays stayed awake, showing the lock screen).
> 
> When I logged back in the external monitor came back on! Sometimes it seemed
> to take a while longer than it's supposed to,
> but after waiting a few seconds more it was ok.
> 
> When the external monitor wakes up it is making a funny little noise. Like a
> low squeaky-door noise? Or a tiny woodpecker?
> I never noticed that before, so I assume it's new. I hope it's not dangerous
> for the device.
> 
> In dmesg I see a new error:
> [  186.476955] i915 0000:00:02.0: [drm] *ERROR* Failed to write the HDMI OEN
> register to the LSPCON: -5
> [  187.585665] i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register
> 0x92
> 
> And, still, a few of these, but not as many as before:
> [  293.825778] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
> [  294.067178] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
> [  294.067181] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
> [  294.067182] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
> 
> So I'm not sure it's a 100% fix, but so far it looks much better than the
> regular kernel, thank You!

Cool, progress! I think? I'm not actually sure that the fix is working correctly here tbqh… Do you think you could get another dmesg with the patch applied after a suspend/resume cycle and with the same kernel args as before:

drm.debug=0x116 log_buf_len=50M

Comment 84 Jan Kolarik 2022-08-04 07:03:19 UTC

I confirm the issue is still valid on current Fedora 36 using Lenovo ThinkPad P1 G3:

Linux fedorage 5.18.15-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jul 31 21:30:34 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Logs after trying to revive the screen after it gone off after the default 5 minutes inactivity period:

[ 3245.791669] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3246.048102] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3246.048112] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3246.048116] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3247.519667] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3247.777099] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3247.777109] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3247.777113] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3309.372546] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3309.614841] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3309.614851] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3309.614854] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3310.016553] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3310.672588] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3310.927009] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3310.927019] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3310.927022] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3311.336526] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3311.587904] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3311.587914] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3311.587917] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3312.144514] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3312.396927] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3312.396938] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3312.396941] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3312.799568] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3313.241556] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3313.488932] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3313.488942] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3313.488946] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed
[ 3313.898387] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode hasn't settled
[ 3314.145938] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change timed out
[ 3314.145941] i915 0000:00:02.0: [drm] *ERROR* LSPCON mode change failed
[ 3314.145942] i915 0000:00:02.0: [drm] *ERROR* LSPCON resume failed

Comment 90 Lyude 2022-09-07 00:06:28 UTC

This bug has taken way too long .____.

Anyway, there has been some progress made - the fix I had hasn't tested consistently on people's machines (thanks for verifying this Lenovo) but I finally have one of these machines in my hands, so I'm going to figure out how to reproduce this and figure out the last remaining bits of this patch this week.

Comment 91 Lyude 2022-09-12 18:17:22 UTC

Been working on trying to reproduce this since friday, no luck yet but there's a good chance I might need a different display to reproduce this. Will get back to y'all as soon as I've got something, ATM this is more or less on the top of my todo list now that I've actually got a machine for it.

Comment 93 Alfonso Martínez 2022-10-19 07:55:38 UTC

The issue is still happening on Fedora 36 with Lenovo ThinkPad P1 Gen3:

$ uname -a
Linux pc1 5.19.15-201.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 13 18:58:38 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

Comment 94 Tom Sorensen 2022-10-27 14:59:50 UTC

I'm also having this issue; F35, P1gen3 with a Samsung 29" 4K monitor (can get model number if helpful). This was very rare until I added a second monitor (an older 23" ViewSonic), and now it's happening every day or two.

Happy to provide whatever logs would be helpful.

Comment 95 ecurtin 2022-10-27 15:05:28 UTC

Since I last upgraded my fw and/or kernel HDMI to my 4k monitor only works via usb 3 dock, but it does work great that way. Just not when directly connected to the laptop.

Comment 98 Alfonso Martínez 2022-11-21 08:38:54 UTC

Hi Lyude,

Do you have any update on this?

The issue is still happening on Fedora 36 with Lenovo ThinkPad P1 Gen3:

$ uname -a
Linux pc1 6.0.8-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:03:58 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

Comment 99 Simone M. Zucchi 2022-11-21 13:08:16 UTC

Hello Team,
is there any news on this bug? I'm also still facing F37:

```
$ uname -a
Linux hostname.domain 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

```

Thanks so very much

Comment 101 Lyude 2022-11-21 20:13:53 UTC

Sorry - I will try getting back to looking at this this week or next

Comment 102 Alfonso Martínez 2022-11-28 10:40:24 UTC

Any update on this?

The issue is still happening on Fedora 36 with Lenovo ThinkPad P1 Gen3:

$ uname -a
Linux pc1 6.0.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:50:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

Comment 103 Ben Cotton 2022-11-29 16:50:08 UTC

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 104 hgomes 2022-12-12 11:06:14 UTC

Hi,
I am facing the same issue as well.

Linux fedora 6.0.12-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 17:15:53 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
	Subsystem: Lenovo Device 22c2
	Kernel driver in use: i915
	Kernel modules: i915

lenovo ThinkPad P1 Gen 3

Comment 105 hgomes 2022-12-12 11:15:20 UTC

Curious finding:
When I power off the laptop, and power on at the "login screen" it works. But as soon as I do the login and go to my workstation it goes off, showing like it doesnt have signal.

Comment 106 Rob Linden 2022-12-12 14:23:53 UTC

Update/workaround for me: I no have/use the thinkpad-dockingstation. It does _not_, by itself, fix the problem. Even with the monitor connected to the HDMI port of the dockingstation it often stays asleep. But it seems that unplugging and reconnecting both the monitor and the laptop from the dockingstation causes the monitor to be detected correctly again -> no power off necessary.

Comment 107 hgomes 2022-12-12 20:02:46 UTC

Yeah, I dont have the dockingstation couldnt find an workaround reliable yet when having the HDMI directly connected.
The only time it worked for me today, it was out of the blue when I didnt have the cable connected, after some time I connected it back and it was working. 
Then the laptop got into suspended mode overtime, and stopped working.

Comment 108 Lyude 2022-12-12 20:38:52 UTC

JFYI I've set up time with an associate from Lenovo to finally hopefully take a look at this on a remote system next week.

Comment 109 jbeitia 2022-12-20 15:25:27 UTC

Having the same issue on Fedora 37, with a T580, using a Lenovo dock, with three external monitors. Absolutely driving me bonkers. 
I have to pull the laptop from it's shelf, open the lid, and login. Then I shut the laptop, and slide it back into it's shelf.

Should this be a new bugzilla, since it's for a different laptop model?

Comment 110 Romain Pelisse 2023-01-09 10:57:16 UTC

I can confirm I have the same problem with Fedora 37 on Lenovo P1. It used to work until a few weeks ago, then it got fix by a couple of reboot (sometimes with a different kernel) and now it just not working. I had to dig out my dock station to get my external screen to work again.

Comment 111 Alfonso Martínez 2023-01-20 13:22:12 UTC

(In reply to Lyude from comment #108)
> JFYI I've set up time with an associate from Lenovo to finally hopefully
> take a look at this on a remote system next week.

Hi Lyude,

Did you have a remote session with the Lenovo associate?
Were you able to find out the root cause?

Kind Regards,

Comment 112 Tom Sorensen 2023-01-26 18:24:49 UTC

Anything on this? My P1Gen3 w/ F37 is sometimes having this happen multiple times a day, and the only way I can fix it is to power the laptop off. Extremely disruptive, since the monitors going to sleep can cause it.

Comment 113 Lyude 2023-01-26 20:09:04 UTC

tl;dr this was something I was going to fix before vacation but the person from Lenovo who I had some testing time setup with had some emergency stuff come up so we had to reschedule, going to be taking another look at this ASAP though

Comment 114 rareddy 2023-01-30 15:57:38 UTC

I also see similar issues with my Lenovo Thinkpad P1 Gen2. Troubles started about a year and a half ago when there was a firmware update that came in for the docking station after the update of the firmware docking station stopped working. I reached out to Lenovo, but they did not know how to roll back the version on the docking station with a Fedora (they wanted me to get a windows boot CD to restore). I switched to the HDMI port on the laptop. Similar issues with the monitor are classified as "unknown" displays with 1024x768 resolution and black screens.

what I have seen consistently is, whenever my system reports that there is a software update, my external monitor on the next sleep wake-up cycle goes dark. I typically log in with a laptop screen and update the software, but that does not fix the issue right away. I typically go into laptop bios and reset the bios to defaults then reboot, then everything works fine until the next software update notification. Sounds a little bizarre but this is what I have been doing and screaming every time this happens :)

Thanks for the pointers I will try the thunderbolt cable to see if this issue gets resolved, seems like I could use new monitor with DP port too :)

Comment 115 hgomes 2023-03-01 20:34:59 UTC

A fyi, using the dock with either 2 HDMI monitors, or HDMI + DP, worked fine.
Nonetheless, the issue is still present when trying to connect a monitor direct to the laptop HDMI cable.

Comment 116 Ben Cotton 2023-04-25 16:41:05 UTC

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.