On a Lenovo T14 on Fedora 37 with an USB C dock connected to two monitors with display port.
After updating to kernel 6.1 an issue with monitors occur when locking screen.
When I try to unlock the session the monitors don’t display anything, only the built-in monitor of the laptop is working.
If I boot on kernel 6.0 everything is OK and the monitors display the login page when I try to unlock the session.
Upgrading to kernel 6.1.x
None yet.
Is this the Lenovo USB-C dock? What model?
Same for me apparently, also on Fedora 37.
My hardware is:
Lenovo Thinkpad X1 Carbon 9th gen with Thunderbolt 3 dock (not officially supported by Lenovo but it worked until kernel 6.0.18-300.fc37, and it so far behaved similar to my ThinkPad Thunderbolt 4 Workstation Dock - I prefer the former because its power supply has much less size and weight).
The symptoms are as follows:
The two external screens connected to the Thunderbolt dock remain black after the laptop is back from energy saving mode (not sure if it’s the laptop or the external screen energy saving, or both), but only after I updated from 6.0.18-300 to 6.1.5-200. An update to kernel 6.1.6-200 (I noticed that also several KDE packages were updated at this time) did not change the behavior. After booting with kernel 6.0.18-300 again, the problem did not happen again. (For the time being, I modified the installonly_limit from 3 to 6 in /etc/dnf/dnf.conf to be able to test another kernel without removing the 6.0 kernel).
I tried to find any output in /var/log/messages at the time of the problem but so far was unsuccessful. I noticed just the following differences:
Kernels 6.1.5-200 and 6.1.6-200 only had the following lines during boot:
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Module Device)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Processor Device)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Processor Aggregator Device)
The three missing lines did not show up anywhere when running with this kernel.
More config info:
The kwin_x11 configuration is shown in /var/log/messages as:
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.3
OpenGL shading language version string: 4.60
Driver: Intel
GPU class: Tiger Lake
OpenGL version: 4.6
GLSL version: 4.60
Mesa version: 22.3.3
X server version: 1.20.14
Linux kernel version: 6.0.18
Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
The only difference in the 6.1 kernels is in the Linux kernel version. The rest remains the same in all cases.
'# echo $XDG_SESSION_TYPE
x11
'# dnf list installed *plasma
Installed Packages
kde-settings-plasma.noarch 37.0-1.fc37 @fedora
kf5-plasma.x86_64 5.102.0-1.fc37 @updates
Apparently, my previous reply disappeared after I edited it. Here it is again:
Same for me apparently, also on Fedora 37.
My hardware is:
Lenovo Thinkpad X1 Carbon 9th gen with Thunderbolt 3 dock (not officially supported by Lenovo but it worked until kernel 6.0.18-300.fc37, and it so far behaved similar to my ThinkPad Thunderbolt 4 Workstation Dock - I prefer the former because its power supply has much less size and weight).
The symptoms are as follows:
The two external screens connected to the Thunderbolt dock remain black after the laptop is back from energy saving mode (not sure if it’s the laptop or the external screen energy saving, or both), but only after I updated from 6.0.18-300 to 6.1.5-200. An update to kernel 6.1.6-200 (I noticed that also several KDE packages were updated at this time) did not change the behavior. After booting with kernel 6.0.18-300 again, the problem did not happen again. (For the time being, I modified the installonly_limit from 3 to 6 in /etc/dnf/dnf.conf to be able to test another kernel without removing the 6.0 kernel).
I tried to find any output in /var/log/messages at the time of the problem but so far was unsuccessful. I noticed just the following differences:
Kernels 6.1.5-200 and 6.1.6-200 only had the following lines during boot:
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Module Device)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Processor Device)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
Jan 17 10:11:47 kernel: ACPI: Added _OSI(Processor Aggregator Device)
The three missing lines did not show up anywhere when running with this kernel.
More config info:
The kwin_x11 configuration is shown in /var/log/messages as:
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.3
OpenGL shading language version string: 4.60
Driver: Intel
GPU class: Tiger Lake
OpenGL version: 4.6
GLSL version: 4.60
Mesa version: 22.3.3
X server version: 1.20.14
Linux kernel version: 6.0.18
Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
The only difference in the 6.1 kernels is in the Linux kernel version. The rest remains the same in all cases.
'# echo $XDG_SESSION_TYPE
x11
'# dnf list installed *plasma
Installed Packages
kde-settings-plasma.noarch 37.0-1.fc37 @fedora
kf5-plasma.x86_64 5.102.0-1.fc37 @updates
I’m using one of these but haven’t rebooted into 6.1 yet. I’ll do that now and report the results.
Oddly enough, I don’t seem to be affected by this. I’m using Gnome with an AMD GPU. Perhaps it’s specific to Intel GPU with this dock?
I’ve checked the type of my USB C Lenovo dock, it’s written TYPE: 40AY.
For the GPU I have an AMD also.
I don’t see anything interesting in the log when I unlock my session maybe I’m missing something…
Mine is a 40AC. According to Display and Video Output Configurations - Docking Stations - Lenovo Support DE, 40AY is a “ThinkPad Universal USB-C Dock” whereas 40AC is a “ThinkPad Thunderbolt 3 Dock”.
Do you also have some differences in /var/log/messages when booting kernel 6.1 vs. 6.0 (e.g. a different number of kernel: ACPI: Added _OSI entries?
I’m seeing similar behaviour with different hardware. I’m hoping that by weighing I can help narrow the commonalities of the root cause.
Under a 6.0.x kernel
Displayport out on the Dock is detected and displayed normally. This is through multiple re-connections of the dock to the Thunderbolt port on the laptop.
Under a 6.1.6 kernel
DisplayPort out on the Dock is detected and displayed normally only the first Connection.
Subsequent connections, the display is detected (EDID, software is aware it’s there and configures it). Display is blank, reporting no Signal.
Attaching a USB-C to DisplayPort Cable between the Thunderbolt port and the Display multiple times works as expected. It’s something about the interaction with the Dock specifically.
Host: HP EliteBook 745 G6
CPU: AMD Ryzen 7 PRO 3700U
GPU: AMD ATI Radeon Vega Series
DE: Plasma 5.26.5
WM: KWin (x11)
HP® Thunderbolt Dock 120W G2 (2UK37UT#ABA)
This thread, regarding a regression for MST Hubs (DisplayPort Multi-Stream Transport), seems likely relevant to be a root cause.
I have a similar issue after upgrading today with the Lenovo YOGA Slim 7 Pro. I am currently running the Linux 6.1.6-200.fc37.x86_64 x86_64 Kernel version and Fedora Linux 37 (Workstation Edition). I didn’t have them in the morning before the upgrade.
Thanks for this. I first assumed that #2171 was only about AMD GPUs, but when looking through https://gitlab.freedesktop.org/superm1/linux/-/commit/2145b4de3fea9908cda6bef0693a797cc7f4ddfc which was referenced in Displays behind MST hubs non-functional (regression in kernel 6.1) (#2171) · Issues · drm / amd · GitLab, I found that also i915 related code was changed, and I also searched for the string MST in /var/adm/messages. Result:
Lines with this string only occurred during times when the system was running with kernel 6.1.
Samples lines are:
Jan 18 08:32:46 kernel: i915 0000:00:02.0: [drm] *ERROR* Step 2 of creating MST payload for 00000000e179ad29 failed: -5
Jan 19 17:31:19 kernel: i915 0000:00:02.0: [drm] Failed to create MST payload for port 00000000f6eacae7: -110
Jan 19 17:31:19 kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to create MST payload for DP-6: -110
Lines of the first type (“Step 2 of creating MST payload…”) appeared most often (total 15 times), whereas each of the other two lines appeared only once.
I installed 6.1.7-200.fc37.x86_64 this morning:
reboot system boot 6.1.7-200.fc37.x Mon Jan 23 09:47 still running
, and so far have had no problems with the external monitors connected to the Thunderbolt dock. I still had some MST lines in /var/log/messages though:
Jan 23 09:48:46 kernel: i915 0000:00:02.0: [drm] Failed to create MST payload for port 00000000835ea903: -110
Jan 23 09:48:46 kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to create MST payload for DP-6: -110
Jan 23 15:05:45 kernel: i915 0000:00:02.0: [drm] Failed to create MST payload for port 00000000f0045e1e: -110
Jan 23 15:05:45 kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to create MST payload for DP-8: -110
Regarding the ACPI: Added _OSI lines: With kernel 6.0.18-300.fc37, there were:
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Module Device)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Processor Device)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Processor Aggregator Device)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Linux-Dell-Video)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
Jan 23 09:32:15 kernel: ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
But with kernel 6.1.7-200.fc37, there are fewer:
Jan 23 09:46:48 kernel: ACPI: Added _OSI(Module Device)
Jan 23 09:46:48 kernel: ACPI: Added _OSI(Processor Device)
Jan 23 09:46:48 kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
Jan 23 09:46:48 kernel: ACPI: Added _OSI(Processor Aggregator Device)
. So these lines are similar to those with kernel versions 6.1.5 and 6.1.6.
However, after reading Displays behind MST hubs non-functional (regression in kernel 6.1) (#2171) · Issues · drm / amd · GitLab, I tried the following:
So what is working with this kernel?
Saw this Thead after postimg my own, it looks like I have the same issue. But it’s not limited to Lenovo’s dock as i have the same issues with an i-tec dock, too.
same issues also with Kernel 6.1.7
Same problem here. Thinkpad z13 and Lenovo Docking Station. I also get a kernel warning:
WARNING: CPU: 7 PID: 2875 at drivers/gpu/drm/amd/amdgpu/…/display/dc/core/dc_link.c:3533 update_mst_stream_alloc_table+0x129/0x130 [amdgpu]
Kernel 6.1.7.200
same problem:
kernel 6.1.5 2/4 ext displays broken
kernel 6.1.6 4/4 ext displays working
kernel 6.1.7 2/4 ext displays broken
[ 309.658012] [drm:dc_link_allocate_mst_payload [amdgpu]] *ERROR* Failure: pbn_per_slot==0 not allowed. Cannot continue, returning DC_UNSUPPORTED_VALUE.
[ 309.936290] [drm:dc_link_allocate_mst_payload [amdgpu]] *ERROR* Failure: pbn_per_slot==0 not allowed. Cannot continue, returning DC_UNSUPPORTED_VALUE
[ 28.279047] ------------[ cut here ]------------
[ 28.279053] WARNING: CPU: 8 PID: 2184 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:3533 update_mst_stream_alloc_table+0x129/0x130 [amdgpu]
[ 28.279472] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer michael_mic nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink bnep sunrpc qrtr_mhi vfat fat btusb btrtl btbcm uvcvideo btintel btmtk videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 bluetooth videobuf2_common snd_usb_audio videodev snd_usbmidi_lib snd_rawmidi mc intel_rapl_msr qrtr ath11k_pci snd_soc_dmic snd_soc_acp6x_mach snd_acp6x_pdm_dma intel_rapl_common ath11k snd_sof_amd_rembrandt snd_sof_amd_renoir snd_sof_amd_acp snd_hda_codec_realtek snd_sof_pci snd_hda_codec_generic snd_hda_codec_hdmi snd_sof edac_mce_amd qmi_helpers snd_hda_intel snd_sof_utils snd_soc_core snd_intel_dspcfg snd_intel_sdw_acpi snd_compress mac80211 ac97_bus kvm_amd snd_hda_codec snd_pcm_dmaengine snd_hda_core snd_pci_ps snd_rpl_pci_acp6x
[ 28.279526] libarc4 snd_pci_acp6x snd_hwdep kvm snd_seq asus_wmi snd_seq_device ledtrig_audio irqbypass sparse_keymap cfg80211 snd_pcm rapl platform_profile snd_timer joydev snd_pci_acp5x wmi_bmof snd_rn_pci_acp3x snd snd_acp_config rfkill snd_soc_acpi k10temp i2c_piix4 thunderbolt snd_pci_acp3x mhi soundcore amd_pmc acpi_cpufreq acpi_tad zram r8152 cdc_mbim cdc_wdm cdc_ncm cdc_ether usbnet mii amdgpu drm_ttm_helper ttm rtsx_pci_sdmmc iommu_v2 gpu_sched mmc_core nvme video uas ucsi_acpi drm_buddy hid_multitouch crct10dif_pclmul crc32_pclmul nvme_core crc32c_intel polyval_clmulni polyval_generic drm_display_helper ghash_clmulni_intel sha512_ssse3 typec_ucsi serio_raw usb_storage sp5100_tco ccp rtsx_pci cec typec nvme_common wmi i2c_hid_acpi i2c_hid ip6_tables ip_tables fuse
[ 28.279587] CPU: 8 PID: 2184 Comm: gnome-shell Not tainted 6.1.7-200.fc37.x86_64 #1
[ 28.279591] Hardware name: OriginPC Voyager a1600/Voyager a1600, BIOS 1.30 08/02/2022
[ 28.279592] RIP: 0010:update_mst_stream_alloc_table+0x129/0x130 [amdgpu]
[ 28.279953] Code: e8 03 89 c1 f3 48 a5 48 81 c4 90 00 00 00 5b 5d 41 5c c3 cc cc cc cc 41 0f b7 40 04 4d 89 19 49 89 59 08 66 41 89 41 10 eb 87 <0f> 0b e9 14 ff ff ff 0f 1f 44 00 00 55 48 89 fd 53 bb 0a 00 00 00
[ 28.279955] RSP: 0018:ffffb09889fb7608 EFLAGS: 00010202
[ 28.279959] RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000000
[ 28.279961] RDX: 0000000000000000 RSI: ffffb09889fb7608 RDI: ffffb09889fb7698
[ 28.279962] RBP: ffff8f1d29980aa0 R08: ffffb09889fb76c0 R09: ffffb09889fb7440
[ 28.279964] R10: ffff8f1cddca1c00 R11: ffff8f1cd44ce9c0 R12: 0000000000000002
[ 28.279965] R13: ffff8f1ceed73000 R14: ffffffffc0e858e0 R15: ffff8f1ccdd04080
[ 28.279967] FS: 00007fdfd047f5c0(0000) GS:ffff8f25d6800000(0000) knlGS:0000000000000000
[ 28.279969] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 28.279971] CR2: 000055c41912515c CR3: 0000000107760000 CR4: 0000000000750ee0
[ 28.279973] PKRU: 55555554
[ 28.279974] Call Trace:
[ 28.279979] <TASK>
[ 28.279985] dc_link_allocate_mst_payload+0x85/0x280 [amdgpu]
[ 28.280382] core_link_enable_stream+0x780/0x930 [amdgpu]
[ 28.280722] dce110_apply_ctx_to_hw+0x649/0x6f0 [amdgpu]
[ 28.281061] dc_commit_state_no_check+0x37e/0xc70 [amdgpu]
[ 28.281388] ? dc_validate_global_state+0x2b0/0x3e0 [amdgpu]
[ 28.281746] dc_commit_state+0x92/0x110 [amdgpu]
[ 28.282076] amdgpu_dm_atomic_commit_tail+0x4a0/0x2a90 [amdgpu]
[ 28.282427] ? load_balance+0x17d/0xdd0
[ 28.282435] ? update_load_avg+0x7e/0x780
[ 28.282438] ? __cgroup_account_cputime+0x4c/0x70
[ 28.282444] ? psi_group_change+0x15f/0x380
[ 28.282449] ? _raw_spin_unlock+0x15/0x30
[ 28.282454] ? finish_task_switch.isra.0+0x9b/0x300
[ 28.282458] ? __switch_to+0x106/0x420
[ 28.282463] ? __schedule+0x367/0x1360
[ 28.282469] ? get_nohz_timer_target+0x18/0x190
[ 28.282473] ? schedule+0x67/0xe0
[ 28.282477] ? schedule_timeout+0xfa/0x140
[ 28.282479] ? preempt_count_add+0x6a/0xa0
[ 28.282482] ? preempt_count_add+0x6a/0xa0
[ 28.282485] ? _raw_spin_lock_irq+0x19/0x40
[ 28.282488] ? _raw_spin_unlock_irq+0x1b/0x40
[ 28.282490] ? wait_for_completion_timeout+0x12a/0x140
[ 28.282494] ? wait_for_completion_interruptible+0x111/0x1b0
[ 28.282498] ? __bpf_trace_dma_fence+0x10/0x10
[ 28.282507] commit_tail+0x94/0x130
[ 28.282512] drm_atomic_helper_commit+0x112/0x140
[ 28.282516] drm_atomic_commit+0x67/0xd0
[ 28.282521] ? drm_plane_get_damage_clips.cold+0x1c/0x1c
[ 28.282525] drm_mode_atomic_ioctl+0x93d/0xb80
[ 28.282532] ? drm_atomic_set_property+0xbb0/0xbb0
[ 28.282535] drm_ioctl_kernel+0xa9/0x150
[ 28.282541] drm_ioctl+0x1e7/0x450
[ 28.282545] ? drm_atomic_set_property+0xbb0/0xbb0
[ 28.282550] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
[ 28.282819] __x64_sys_ioctl+0x90/0xd0
[ 28.282825] do_syscall_64+0x5b/0x80
[ 28.282830] ? exit_to_user_mode_prepare+0x18f/0x1f0
[ 28.282835] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 28.282839] RIP: 0033:0x7fdfd3f23d6f
[ 28.282874] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 28.282876] RSP: 002b:00007ffd2c7fd770 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 28.282879] RAX: ffffffffffffffda RBX: 000055c41b9dcc40 RCX: 00007fdfd3f23d6f
[ 28.282881] RDX: 00007ffd2c7fd810 RSI: 00000000c03864bc RDI: 000000000000000a
[ 28.282882] RBP: 00007ffd2c7fd810 R08: 0000000000000013 R09: 0000000000000013
[ 28.282884] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc
[ 28.282885] R13: 000000000000000a R14: 000055c4199d5d00 R15: 000055c41be3c7b0
[ 28.282889] </TASK>
[ 28.282890] ---[ end trace 0000000000000000 ]---
RX 6800M on corsair voyager a1600
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M] (rev c3)
68:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] (rev c8)
6.1.8-200 Problem is still present … So when can we expect a fix for this problem?
The fix will come from upstream, and likely the kernel. To install a newer kernel, you have a few options, in order from most likely to be supported vs least:
This all comes with the caveat that none of these methods are guaranteed to fix your problem and you might be more likely to introduce new problems by installing kernels that haven’t gone through full community testing, and you might have limited community support running a custom kernel if you go down the compiling your own route. I’m not discouraging you from doing this, as I’ve definitely done this all myself when waiting for some fix or patch to land for my hardware, but it’s good to have a sort of “this hiking trail doesn’t have guard rails” sign up front.
Does someone maybe have a proposal for which diagnostics information we can/should collect for solving problems with external monitors connected to docking stations, and where to report such data?
BTW - Even with the 6.0.18-300 kernel, the two external monitors sometimes do not display content after the system comes back from energy saving (can be solved by disconnecting the docking station and connecting it again. Unfortunately, I don’t remember and don’t have any data about which kernel was the last one without such problems. I believe these problems started at some time in the second half 2022.
I’d be happy to spend some time on analyzing these types of problems and work on proposals for kernel regression tests - as it seems that such tests are not yet part of KernelRegressionTests - Fedora Project Wiki .