[i915] Using gnome-shell with a USB-C dock causes the kernel to log "adding CRTC not allowed without modesets" and crashes in drm_atomic_check_only

Thanks for the bug report.

The biggest issue here seems to be a kernel crash:

Jan 16 19:40:28 semiauto kernel: [84513.834489] adding CRTC not allowed without modesets: requested 0x4, affected 0x7
Jan 16 19:40:28 semiauto kernel: [84513.834564] WARNING: CPU: 4 PID: 2041 at drivers/gpu/drm/drm_atomic.c:1403 drm_atomic_check_only+0x40c/0x450 [drm]

But it sounds like the kernel is complaining that gnome-shell is to blame. To work around that, please try adding:

  MUTTER_DEBUG_FORCE_KMS_MODE=simple

to /etc/environment and then reboot.

But there are three different crashes here and we need separate bugs opened for each. The other two crashes are of 'gjs-console' and I can see 'gnome-shell' also crashed according to the log. Please open new bugs about each of those by following https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

There is an upstream kernel bug suggesting it is triggered by using a USB-C or Thunderbolt dock. That's what it sounds like to me too...

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

This *might* relate to bug 2003042.

Spelling error : "When I woke the machine..."

Yes, there is a USB-C "port extender" (dock) attached to this Lenovo laptop. The model is the MUC-0501B. It is this exact device : https://amzn.to/3XA5u5N -- "USB C Adapters for MacBook Pro/Air,Mac Dongle with 3 USB Port,USB C to HDMI, USB C to RJ45 Ethernet,MOKiN 9 in 1 USB C to HDMI Adapter,100W Pd Charging, USB C to SD/TF Card Reader USB C Hub".

I also have noticed occassional flickering. What's interesting is that either the display controlled via this, or via the direct HDMI port will "drop out" for a second or 2 when the mouse moves between the screens. If I move the mouse back to the alternate screen, the display comes back.

I have applied the workaround for mutter :
  MUTTER_DEBUG_FORCE_KMS_MODE=simple

I am seeing no further logs at the moment. I will continue to monitor for issues.

To address any low-level issues I also have applied the system firmware update, available via ISO from the Lenovo support site "n32ur20w.iso". the release date on this was Jan 02 , 2023, so only about 2 weeks ago.

I expect the issue to re-occur.

Reference for anyone following along at home : https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-yoga-6th-gen-type-20xy-20y0/20xy/20xy0027us/downloads/driver-list/component?name=BIOS%2FUEFI

Release notes for this firmware update included here too :

Ok, I am getting a slightly different, but perhaps related problem with another USB-C / eGPU encapsulation (PCIE tunneles over USB-C basically) device.

I've done some testing with the Razer Core X Chroma, a USB-C connected Thunderbolt 3 eGPU enclosure. Reference to hardware is here : https://www.razer.com/gaming-egpus/Razer-Core-X/RC21-01430100-R3U1

I have 2x displays now connected to the internal PCIE nVidia TU117 [GeForce GTX 1650] loaded in the unit. The BIOS seems to work fine, , but when I get to the gnome login screen things hang. I am narrowing it down, but just like the display blanking on the Intel based on cursor location, I am seeing the same behavior with this enclosure - if at boot time the enclosure is connected, then the displays will lock up. If, I move the mouse to the right edge of the screen , the desktop will also lock up.

Attached are the logs of the attachment, then detachment of this enclosure. Note that on re-attaching the enclosure the USB devices which previously worked fine attached to the enclosure no longer function (perhaps not deregistered properly?).

Details for HW info

beadon@semiauto:~$ hwinfo --gfxcard --short
graphics card:
                       nVidia TU117 [GeForce GTX 1650]
                       Intel TigerLake-LP GT2 [Iris Xe Graphics]

Primary display adapter: #26

Should I open this as a different issue with the Core X Chroma Thunderbolt 3 enclosure ? It's very similar.

Please report all issues not relating to "adding CRTC not allowed without modesets" as new bugs.

Comment #8 is a crash in the 'nouveau' kernel driver unrelated to this bug. Although you should technically report a new bug for that, 'nouveau' is not very well maintained and we would always just recommend using the 'Additional Drivers' app to install one of the official Nvidia drivers instead.

I have blacklisted this now using:

sudo vim /etc/modprobe.d/blacklist-nouveau.conf

adding:

blacklist nouveau
options nouveau modeset=0

That's probably not as good as sticking to nouveau because it will fall back to software rendering instead. But the third and best option is to install an Nvidia driver using the 'Additional Drivers' app.

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

This issue might be kernel related and not mutter related. I am running kubuntu 23.04 with kde plasma 5.27.4 with kwin under wayland and when plugging in to a usbc to HDMI adapter I received the kernel warning: "adding CRTC not allowed without modesets: requested 0x2, affected 0x3".

Machine: Dell XPS 17 9720 (2022)
CPU: intel core i9 12900HK
GPU: RTX 3060 6GB + intel Xe graphics
Nvidia driver: 535.54.03-0ubuntu1 (proprietary)
OS: Kubuntu 23.04 (Lunar)
Desktop environment: Plasma 5.27.4
Compositor: Wayland
Window manager: Kwin
kernel: 6.2.0-25-generic

Attached is my dmesg output.

I think this sounds like it could still be a common bug to both mutter and kwin so let's keep that open. Certainly the circumstances agree with the error message and it sounds logical to me that the compositor could be to blame.