Window manager freezes when plugging in USB-C dock with external monitor ([drm] *ERROR* mstb 00000000f21f0a30 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed)

EDIT: Updated title.

Taking the dock out of the loop and simply plugging in an HDMI monitor also causes the problem. Below is the syslog from single plug/unplug cycle.

```
$ tail -f /var/log/syslog
Apr 26 18:54:49 dathon systemd[1]: Starting Hostname Service...
Apr 26 18:54:49 dathon nautilus[7520]: Called "net usershare info" but it failed: Failed to execute child process “net” (No such file or directory)
Apr 26 18:54:49 dathon dbus-daemon[463]: [system] Successfully activated service 'org.freedesktop.hostname1'
Apr 26 18:54:49 dathon systemd[1]: Started Hostname Service.
Apr 26 18:54:49 dathon rtkit-daemon[905]: Supervising 6 threads of 3 processes of 1 users.
Apr 26 18:54:49 dathon rtkit-daemon[905]: message repeated 5 times: [ Supervising 6 threads of 3 processes of 1 users.]
Apr 26 18:54:49 dathon rtkit-daemon[905]: Successfully made thread 7601 of process 7406 owned by '1000' RT at priority 10.
Apr 26 18:54:49 dathon rtkit-daemon[905]: Supervising 7 threads of 4 processes of 1 users.
Apr 26 18:55:02 dathon rtkit-daemon[905]: message repeated 12 times: [ Supervising 7 threads of 4 processes of 1 users.]
Apr 26 18:55:19 dathon systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Apr 26 18:55:35 dathon gnome-shell[1649]: Spurious clutter_actor_allocate called for actor 0x55ebc7aac030/<dashtodockContainer>[<Gjs_ubuntu-dock_ubuntu_com_docking_DashToDock>:0x55ebc7aac030] which isn't a descendent of the stage!
Apr 26 18:55:35 dathon gnome-shell[1649]: Timelines with detached actors are not supported. <dashtodockContainer>[<StBin>:0x55ebc7679c30] in animation of duration 500ms but not on stage.
Apr 26 18:55:35 dathon gnome-shell[1649]: Timelines with detached actors are not supported. <dashtodockContainer>[<StBin>:0x55ebc73bf090] in animation of duration 500ms but not on stage.
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 35 with keysym 35 (keycode e).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 32 with keysym 32 (keycode b).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 33 with keysym 33 (keycode c).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 31 with keysym 31 (keycode a).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 36 with keysym 36 (keycode f).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 37 with keysym 37 (keycode 10).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 38 with keysym 38 (keycode 11).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 39 with keysym 39 (keycode 12).
Apr 26 18:55:36 dathon gnome-shell[1649]: Window manager warning: Overwriting existing binding of keysym 34 with keysym 34 (keycode d).
Apr 26 18:55:36 dathon gnome-shell[1649]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Apr 26 18:55:46 dathon...

Status changed to 'Confirmed' because the bug affects multiple users.

Next time the freeze happens, please:

1. Wait 10 seconds.

2. Reboot.

3. Run:

   journalctl -b-1 > prevboot.txt

4. Attach the resulting text file here.

5. Also check for crashes by following the steps in https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

Also it sounds like selecting 'Ubuntu on Xorg' from the login screen might avoid the problem.

Maybe related: bug 1970043

What is the model of the USB-C dock? Many/most of them use DisplayLink technology and so require that special kernel driver be installed first:

https://www.synaptics.com/products/displaylink-graphics/downloads/ubuntu

I would like to mention same issue here either with c-dock or direct HDMI plugin.

Pradeep, if you are experiencing a similar bug with a different root cause then commenting here may cause confusion. It's probably better if you open a new bug of your own by running:

  ubuntu-bug gnome-shell

so that we can see the unique circumstances of your machine.

I will go ahead and do so though I do want to mention I had no issues when using the live installer with hdmi and was able to use it perfectly

@Daniel

(1) It's not possible to do a soft reboot under the error mode because the displays are frozen. Will a hard power-off get the job done?

(2) Using "Ubuntu on Xorg" changed the symptoms somewhat, but the outcome is still the same: the secondary monitor never cycles up -- it stays black. The only difference is that, under Xorg, the primary monitor does NOT freeze. I can even access the Display Manager and attempt to set the secondary display up, but clicking "apply" has no effect other than to cycle the power on the monitor.

(3) The dock did not require any special drivers on 20.04, the Ubuntu version I just switched from.

I will attempt to collect additional logs under Wayland. Stay tuned.

This is a DisplayPort-related issue. At the office, I was able able to try out an HDMI-only dock. The problem did NOT occur, and everything worked perfectly.

Back at home, I switched my personal dock from DisplayPort to HDMI by changing out the cables and, thus, using the dock's HDMI ports instead. The problem went away.

Yes a hard power-off is fine so long as you've waited 10 seconds first per comment #4.

I believe I have the same issue. Dell XPS 13 9360 laptop connected to a Dell U3011 monitor using a CableMatters USB-C to Displayport adapter. When I plug my laptop the GNOME shell is almost completely unresponsive. I can use the active window but I cannot switch windows. The only reproducible way I have found to get out of it, other than to reboot, is to unplug the USB-C adapter, logout of the session, re-plug the USB-C adapter and login again. This behavior was not present with Ubuntu 21.10 and it started after updating to Ubuntu 22.04.

I use an X11 session type:
$ echo $XDG_SESSION_TYPE
x11

Using journalctl, output attached, there are many logs from the gnome-shell binary, such as this:
gnome-shell[###]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
gnome-shell[###]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed

^^^
Surprising, that was declared fixed some time ago in bug 1722811 and bug 1717170. If the same errors don't appear in Brian's logs (still waiting for them) then please open a new bug.

Same errors in my syslog. See full text of https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970495/comments/2

Relevant snippet:
```
Apr 26 18:57:17 dathon gnome-shell[1649]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Apr 26 18:57:17 dathon gnome-shell[1649]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Apr 26 18:57:17 dathon gnome-shell[1649]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Apr 26 18:57:17 dathon gnome-shell[1649]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Apr 26 18:57:17 dathon gnome-shell[1649]: JS ERROR: TypeError: monitor is undefined#012vfunc_allocate@resource:///org/gnome/shell/ui/workspace.js:1042:29#012_prepareMainDash/<@/<email address hidden>/docking.js:2159:18#012vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:555:25#012vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:711:30

```

Hopefully that's sufficient as I'm not going to have any time to spend on further debugging this week.

Hmm, maybe we still need to treat those errors as a separate bug. If you look at a full system log like in comment #14 then you see the errors occurring many times. But presumably the "freeze" here does not occur many times. So they may not be the cause of the freeze.

Is anyone else seeing kernel messages like this (from bug 1971536)?

kernel: i915 0000:00:02.0: [drm] *ERROR* mstb 00000000caa481c4 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed

Does the situation improve if you add this to /etc/environment?;

  MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0

Does it at least replace the freeze with just one black screen?

I *did* see those messages when I was initially debugging the problem. This is from dmesg in one of the logs I made:

```
[ 20.525519] amdgpu 0000:07:00.0: [drm] *ERROR* mstb 00000000f21f0a30 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[ 20.570355] amdgpu 0000:07:00.0: [drm] *ERROR* mstb 00000000f21f0a30 port 2: DPCD read on addr 0x4b0 for 1 bytes NAKed
[ 20.614750] amdgpu 0000:07:00.0: [drm] *ERROR* mstb 00000000f21f0a30 port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
```

At the time, I tried MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 and didn't see any change. The only thing that worked was switching the monitors from DisplayPort to HDMI on the dock.

> The only thing that worked was switching the monitors from DisplayPort to HDMI on the dock.

That's consistent with the kernel error in comment #20 and consistent with comment #12, since MST is a DisplayPort feature.

I can reproduce this issue, too.
When plug in the dock(with HDMI 4k monitor), the screen freeze and keyboard/touchpad won't work, but I still can ssh into the machine.
Un-plug the dock, everything works again.

BTW, I found gnome-shell runs in 100% while the issue happened, and un-plug the dock the CPU usage of gnome-shell comes back to normal.

Hi, same error occur to me. Dell XPS 17 9710. Ubuntu 22.04, Wayland.

```
[387809.776955] i915 0000:00:02.0: [drm] *ERROR* mstb 00000000586103bb port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[387809.782229] i915 0000:00:02.0: [drm] *ERROR* mstb 00000000586103bb port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[387809.794145] i915 0000:00:02.0: [drm] *ERROR* mstb 00000000586103bb port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[387809.799458] i915 0000:00:02.0: [drm] *ERROR* mstb 00000000586103bb port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[387809.810277] i915 0000:00:02.0: [drm] *ERROR* mstb 00000000586103bb port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
```

My Thinkpad X1 gen 6 with Ubuntu 22.04, Lenovo 40AJ dock with 4K LG monitor with DP cable, will sometimes just show 2 or 4 lines with "DPCD read on addr 0x4b0 for 1 bytes NAKed", after which the system will just continue to work. But sometimes the "1 bytes NAKed" messages just keep running - which is when the session will crash, eventually.

If I connect the dock with the laptop LCD on, the "1 bytes NAKed" will freeze the LCD. When I'm fast enough to disconnect the DP cable, the LCD unfreezes. However, reconnecting the DP will re-freeze the LCD.

Experiencing similar issue frequently with Thinkpad T490 using Ubuntu 20.04 and Thinkpad TB3 dock with two external displays connected via DisplayPort. Occasionally have seen "UBSAN: shift-out-of-bounds" and "UBSAN: invalid-load" errors in addition to "DPDC read NAKed" when connecting the dock, perhaps it is related since those seem to happen in drivers/gpu/drm/drm_dp_mst_topology.c:
---
Dec 23 08:44:24 T490 kernel: [17945.078994] ================================================================================
Dec 23 08:44:24 T490 kernel: [17945.078995] UBSAN: invalid-load in /build/linux-hwe-5.15-jemPrJ/linux-hwe-5.15-5.15.0/drivers/gpu/drm/drm_dp_mst_topology.c:2426:10
Dec 23 08:44:24 T490 kernel: [17945.078998] load of value 64 is not a valid value for type '_Bool'
Dec 23 08:44:24 T490 kernel: [17945.078999] CPU: 6 PID: 37158 Comm: kworker/6:5 Tainted: P O 5.15.0-56-generic #62~20.04.1-Ubuntu
Dec 23 08:44:24 T490 kernel: [17945.079001] Hardware name: LENOVO 20N2000MMX/20N2000MMX, BIOS N2IETA0W (1.78 ) 10/14/2022
Dec 23 08:44:24 T490 kernel: [17945.079002] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079020] Call Trace:
Dec 23 08:44:24 T490 kernel: [17945.079021] <TASK>
Dec 23 08:44:24 T490 kernel: [17945.079022] dump_stack_lvl+0x4a/0x63
Dec 23 08:44:24 T490 kernel: [17945.079025] dump_stack+0x10/0x16
Dec 23 08:44:24 T490 kernel: [17945.079028] ubsan_epilogue+0x9/0x49
Dec 23 08:44:24 T490 kernel: [17945.079030] __ubsan_handle_load_invalid_value.cold+0x44/0x49
Dec 23 08:44:24 T490 kernel: [17945.079033] ? drm_dp_mst_add_port+0xd1/0x100 [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079051] drm_dp_mst_handle_link_address_port.cold+0x285/0x32f [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079070] drm_dp_send_link_address+0x261/0x440 [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079089] drm_dp_check_and_send_link_address+0xdf/0x100 [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079107] ? drm_dp_mst_link_probe_work+0x157/0x1a0 [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079125] drm_dp_mst_link_probe_work+0x162/0x1a0 [drm_kms_helper]
Dec 23 08:44:24 T490 kernel: [17945.079143] process_one_work+0x228/0x3d0
Dec 23 08:44:24 T490 kernel: [17945.079146] worker_thread+0x4d/0x3f0
Dec 23 08:44:24 T490 kernel: [17945.079149] ? process_one_work+0x3d0/0x3d0
Dec 23 08:44:24 T490 kernel: [17945.079152] kthread+0x127/0x150
Dec 23 08:44:24 T490 kernel: [17945.079154] ? set_kthread_struct+0x50/0x50
Dec 23 08:44:24 T490 kernel: [17945.079156] ret_from_fork+0x1f/0x30
Dec 23 08:44:24 T490 kernel: [17945.079160] </TASK>
Dec 23 08:44:24 T490 kernel: [17945.079161] ================================================================================
...
Dec 23 08:44:26 T490 kernel: [17946.090948] i915 0000:00:02.0: [drm] *ERROR* mstb 000000005985afcd port 70: DPCD read on addr 0x4b0 for 1 bytes NAKed
Dec 23 08:44:26 T490 kernel: [17946.357170] ================================================================================
Dec 23 08:44:26 T490 kernel: [17946.357177] UBSAN: shift-out-of-bounds in /build/linux-hwe-5.15-jemPrJ/linux-hwe-5.15-5.15.0/dri...

See also bug 2000173

Sounds like the kernel error message is harmless:
https://lists.freedesktop.org/archives/dri-devel/2022-February/342776.html

So just correlated with other USB-C dock issues, not the cause of them.

Given the Bug Description says the problem doesn't occur in the live installer session, that suggests this is Wayland specific or even specific to atomic KMS. So please try the workaround from comment #19.

Here are two full logs. One where things go wrong. I'm walking upstairs at 06:15 and at 06:16:17, the first logs indicate that the dock is connected ("usb 1-4: new high-speed USB device number 53 using xhci_hcd"), the "Cypress Semiconductor؀ USB Billboard" shows up 0.7 seconds later.

Please note that the "pci 0000:05:00.0: BAR 13: no space for [io size 0x4000]" seem harmless, they also do occur on a successful docking attempt.

At 06:16:22, Thunderbird starts complaining, "Couldn't map window ....", and 06:16:23 gnome-shell complains that an assertion about monitors failed. I didn't check the source code.

Apparently, I'm impatient today, so I'm unplugging the dock again at 06:16:54, replugging it 06:17:04 because I saw a login screen i.e. my session had crashed anyway and probably removing it again after a few seconds. So all info after 06:17:14 or so should be regarded as "utter mess, please ignore". I tried a few things afterwards, but basically switching to tty2 and rebooted the system (at 06:20).

I'll add a successful docking attempt log file in the next comment.

This is a successful docking attempt.

I rebooted my laptop with the dock attached. At about 06:30:30, I decide to remove the dock, in order to try to replicate the behaviour. At 06:30:37 I'm plugging it in again.

I have not redacted these logs, no obfuscation etc, so yeah, you can see all the slack.desktop etcetera messages. I hope someone can make something of this. I can't. I'm just seeing my desktop crash randomly and I don't know where it comes from.

Best regards,

Valentijn

Might be a Wayland bug after all:
jul 17 06:49:40 X1-carbon gnome-shell[3140]: XWAYLAND: mode -1x-1 is not available

... is the recurring error message (between lots of "thunderbird[3569]: Couldn't map window 0x7f4cbe67ab20 as subsurface because its parent is not mapped." and other processes that don't know where to put their windows)

Connecting the dock without monitor is fine. Then connecting the DisplayPort connector:
aug 10 10:40:28 X1-carbon thunderbird[95811]: Couldn't map window 0x7f892a156640 as subsurface because its parent is not mapped.
aug 10 10:40:28 X1-carbon thunderbird[95811]: Couldn't map window 0x7f890f70caa0 as subsurface because its parent is not mapped.
aug 10 10:40:28 X1-carbon thunderbird[95811]: Couldn't map window 0x7f890f70d600 as subsurface because its parent is not mapped.
[...] continues this way, until more alarming messages start showing up, "gnome-shell[2767]: WL: error in client communication (pid 151710)" and finally "gnome-shell[2767]: WL: error in client communication (pid 2767)" and journal is added as attachment. Eventually I'm removing the monitor cable again and things come to a rest.

Then I tried to suspend; resume with monitor attached. Didn't work either - see second log file.

(One thing I'm wondering: I *am* using the same brand and type of monitor, connected to the same brand and type of dock, at *different places*. Could that be the culprit? I.e. having used the LG Electronics HDR 4K somewhere, then attaching the laptop to the same brand and type of monitor at a different place, with a different dock, would that possibly lead to this behaviour? Could others comment on this, i.e. do you experience this behaviour when using a single dock / single work place?)