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.
Created attachment 1725789 [details] dmesg from an affected boot with drm.debug=0x116
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 ]---
These warnings did not appear when booting the system with drm.debug=0x116 (although the problem still occurs).
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.
Locking the screen isn't necessary - I just found it to trigger it quite reliably in my testing.
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
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.
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
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
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
Possibly related: https://gitlab.freedesktop.org/drm/intel/-/issues/2145
Did this HDMI/LSPCON port work on earlier kernel versions? Is there an HDMI firmware upgrade for the failing platforms?
(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)
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
(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
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?
(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
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.
(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?
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
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.
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.
(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 ...
Created attachment 1841478 [details] log from dpms off ... dpms on by: journalctl --since '2021-11-12 18:20'
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
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.
I have the same troubles Fedora 35.
In my opinion, the same issue is: https://gitlab.freedesktop.org/drm/intel/-/issues/2145
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/
(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 :(
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.
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.
(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.
(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.
(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)
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.
(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 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.
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.
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
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
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
(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?
(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)
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.
Created attachment 1871383 [details] HP LP2465 QuickSpecs
BTW, my current monitor, that works flawlessly, is a Samsung LU28R552UQRXEN
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
Switching between kernel versions doesn't help once it starts...
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.
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.
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
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
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).
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.
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
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
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...
On a fresh startup, monitor works, but returning from suspend, errors appears again
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 ?
(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
(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!
(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!
(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
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
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.
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.
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
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.
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.
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
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
Sorry - I will try getting back to looking at this this week or next
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
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.
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
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.
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.
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.
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.
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?
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.
(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,
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.
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
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 :)
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.
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.