Issues with USB-C alt mode dock

Bidski · 2025-09-17 23:18:39

I have been setting up a new laptop recently and trying to use a USB-C dock which utilises the USB-C DisplayPort alt mode. The dock contains 2 HDMI ports, an ethernet port, a couple of USB ports, and an SD card reader.

Not sure what is relevant in terms of the setup/configuration of the laptop, but heres some of the details

Whole drive encryption with TPM
Secure Boot with unified kernel image
Gnome + GDM
Nvidia RTX 5060 with nvidia-open-dkms drivers
Intel Arrow Lake-S graphics
Intel Meteor Lake-P chipset
I have i915 driver listed in the modules for mkinitcpio and kms in the hooks

lspci output

00:00.0 Host bridge: Intel Corporation Device 7d1c (rev 01)
00:02.0 VGA compatible controller: Intel Corporation Arrow Lake-S [Intel Graphics] (rev 06)
00:04.0 Signal processing controller: Intel Corporation Device ad03 (rev 01)
00:06.0 PCI bridge: Intel Corporation Device ae4d (rev 10)
00:08.0 System peripheral: Intel Corporation Device ae4c (rev 10)
00:0a.0 Signal processing controller: Intel Corporation Device ad0d (rev 01)
00:0b.0 Processing accelerators: Intel Corporation Arrow Lake NPU (rev 01)
00:0d.0 USB controller: Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller (rev 10)
00:14.0 RAM memory: Intel Corporation Device ae7f (rev 10)
00:1f.0 ISA bridge: Intel Corporation Device ae10 (rev 10)
00:1f.5 Serial bus controller: Intel Corporation Device ae23 (rev 10)
01:00.0 VGA compatible controller: NVIDIA Corporation GB206M [GeForce RTX 5060 Max-Q / Mobile] (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 22eb (rev a1)
80:14.0 USB controller: Intel Corporation Device 7f6e (rev 10)
80:14.5 Non-VGA unclassified device: Intel Corporation Device 7f2f (rev 10)
80:15.0 Serial bus controller: Intel Corporation Device 7f4c (rev 10)
80:15.2 Serial bus controller: Intel Corporation Device 7f4e (rev 10)
80:15.3 Serial bus controller: Intel Corporation Device 7f4f (rev 10)
80:16.0 Communication controller: Intel Corporation Device 7f68 (rev 10)
80:19.0 Serial bus controller: Intel Corporation Device 7f7a (rev 10)
80:19.1 Serial bus controller: Intel Corporation Device 7f7b (rev 10)
80:1c.0 PCI bridge: Intel Corporation Device 7f3e (rev 10)
80:1c.7 PCI bridge: Intel Corporation Device 7f3f (rev 10)
80:1d.0 PCI bridge: Intel Corporation Device 7f34 (rev 10)
80:1f.0 ISA bridge: Intel Corporation Device 7f0c (rev 10)
80:1f.3 Audio device: Intel Corporation Device 7f50 (rev 10)
80:1f.4 SMBus: Intel Corporation Device 7f23 (rev 10)
80:1f.5 Serial bus controller: Intel Corporation Device 7f24 (rev 10)
81:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
82:00.0 Network controller: Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 (rev 1a)
83:00.0 Non-Volatile memory controller: Micron/Crucial Technology P310 NVMe PCIe SSD (DRAM-less) (rev 01)

Most of the setup seems to work fine, but the DisplayPort alt mode is flakey. Most boots result in the laptop screen working with the external monitors remaining blank. The keyboard, mouse, and ethernet plugged into the dock all work, just not the monitors. In these instances I can usually swap to a tty and

sudo systemctl restart gdm

and the external monitors will start then become active.

Some boots seem to work fine with all external monitors working, but they wont turn on until after logging in to Gnome.

Other boots will only have the laptop screen and there will be this message in the system logs

usb usb4-port1: Cannot enable. Maybe the USB cable is bad?

I tried to add the nvidia modules to mkinitcpio as well and the external monitors came up at boot/login but they continuously cycled between on and off (the monitors turned on and showed a blank screen, then almost immediately showed the signal lost banner). The monitors were on enough for Gnome to move its top bar to one of the external monitors (as is set in my preferences). I had to unplug and replug the dock to fix this

Here is the output of journalctl -b0 with only i915 in the modules for mkinitcpio. This boot resulted in only the laptop monitor working and the bad cable message http://0x0.st/KcC9.txt

Here is the output of journalctl -b0 with i915 and the nvidia modules in mkinitcpio. This boot resulted in the monitors cycling between on/off http://0x0.st/KcCp.txt

contents of mkinitcpio.conf http://0x0.st/KcCf.txt

output of inxi -F http://0x0.st/KcCW.txt

I feel like this is something to do with the graphics drivers not being loaded at the correct time, but I am at a complete loss as to what needs tweaking and in what way to make everything happy here.

Can anyone shed some light on how I can get more consistent results from this setup?

Bidski · 2025-09-23 23:28:15

After an update yesterday (September 23 2025) I started getting the following error at boot (full log //0x0.st/Kmot.txt)

Sep 23 10:41:54 4AISLT001 systemd[1]: Started Session 11 of User gdm-greeter.
Sep 23 10:41:54 4AISLT001 gdm[1887]: Gdm: GdmSession: no session desktop files installed, aborting...
Sep 23 10:41:54 4AISLT001 kernel: traps: gdm[1887] trap int3 ip:7fb15e66264b sp:7ffe2ad47e70 error:0 in libglib-2.0.so.0.8600.0[6564b,7fb15e61b000+a7000]
Sep 23 10:41:54 4AISLT001 systemd-coredump[1903]: Process 1887 (gdm) of user 0 terminated abnormally with signal 5/TRAP, processing...
Sep 23 10:41:54 4AISLT001 systemd[1]: Started Process Core Dump (PID 1903/UID 0).
Sep 23 10:41:54 4AISLT001 systemd-coredump[1904]: [?] Process 1887 (gdm) of user 0 dumped core.
                                                  
                                                  Stack trace of thread 1887:
                                                  #0  0x00007fb15e66264b g_logv (libglib-2.0.so.0 + 0x6564b)
                                                  #1  0x00007fb15e662904 g_log (libglib-2.0.so.0 + 0x65904)
                                                  #2  0x000055a753d8dddc n/a (/usr/bin/gdm + 0x33ddc)
                                                  #3  0x000055a753d94b65 n/a (/usr/bin/gdm + 0x3ab65)
                                                  #4  0x00007fb15e23bac6 n/a (libffi.so.8 + 0x7ac6)
                                                  #5  0x00007fb15e23876b n/a (libffi.so.8 + 0x476b)
                                                  #6  0x00007fb15e23b06e ffi_call (libffi.so.8 + 0x706e)
                                                  #7  0x00007fb15e76d818 g_cclosure_marshal_generic_va (libgobject-2.0.so.0 + 0x18818)
                                                  #8  0x00007fb15e787c77 n/a (libgobject-2.0.so.0 + 0x32c77)
                                                  #9  0x00007fb15e787d89 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32d89)
                                                  #10 0x00007fb15e787e44 g_signal_emit (libgobject-2.0.so.0 + 0x32e44)
                                                  #11 0x000055a753d921f2 n/a (/usr/bin/gdm + 0x381f2)
                                                  #12 0x00007fb15e4d39cc n/a (libgio-2.0.so.0 + 0xa89cc)
                                                  #13 0x00007fb15e4d9472 n/a (libgio-2.0.so.0 + 0xae472)
                                                  #14 0x00007fb15e54d9ce n/a (libgio-2.0.so.0 + 0x1229ce)
                                                  #15 0x00007fb15e4d39cc n/a (libgio-2.0.so.0 + 0xa89cc)
                                                  #16 0x00007fb15e4d9472 n/a (libgio-2.0.so.0 + 0xae472)
                                                  #17 0x00007fb15e5438b3 n/a (libgio-2.0.so.0 + 0x1188b3)
                                                  #18 0x00007fb15e4d39cc n/a (libgio-2.0.so.0 + 0xa89cc)
                                                  #19 0x00007fb15e4d3a15 n/a (libgio-2.0.so.0 + 0xa8a15)
                                                  #20 0x00007fb15e65bf4d n/a (libglib-2.0.so.0 + 0x5ef4d)
                                                  #21 0x00007fb15e65d617 n/a (libglib-2.0.so.0 + 0x60617)
                                                  #22 0x00007fb15e65d9d7 g_main_loop_run (libglib-2.0.so.0 + 0x609d7)
                                                  #23 0x000055a753d6722f n/a (/usr/bin/gdm + 0xd22f)
                                                  #24 0x00007fb15e027675 n/a (libc.so.6 + 0x27675)
                                                  #25 0x00007fb15e027729 __libc_start_main (libc.so.6 + 0x27729)
                                                  #26 0x000055a753d67595 n/a (/usr/bin/gdm + 0xd595)
                                                  
                                                  Stack trace of thread 1893:
                                                  #0  0x00007fb15e11876d syscall (libc.so.6 + 0x11876d)
                                                  #1  0x00007fb15e68c7ee g_cond_wait (libglib-2.0.so.0 + 0x8f7ee)
                                                  #2  0x00007fb15e6231cd n/a (libglib-2.0.so.0 + 0x261cd)
                                                  #3  0x00007fb15e695447 n/a (libglib-2.0.so.0 + 0x98447)
                                                  #4  0x00007fb15e69487c n/a (libglib-2.0.so.0 + 0x9787c)
                                                  #5  0x00007fb15e0969cb n/a (libc.so.6 + 0x969cb)
                                                  #6  0x00007fb15e11aa0c n/a (libc.so.6 + 0x11aa0c)
                                                  
                                                  Stack trace of thread 1894:
                                                  #0  0x00007fb15e09f042 n/a (libc.so.6 + 0x9f042)
                                                  #1  0x00007fb15e0931ac n/a (libc.so.6 + 0x931ac)
                                                  #2  0x00007fb15e0931f4 n/a (libc.so.6 + 0x931f4)
                                                  #3  0x00007fb15e10da36 ppoll (libc.so.6 + 0x10da36)
                                                  #4  0x00007fb15e65d744 n/a (libglib-2.0.so.0 + 0x60744)
                                                  #5  0x00007fb15e65d825 g_main_context_iteration (libglib-2.0.so.0 + 0x60825)
                                                  #6  0x00007fb15e65d872 n/a (libglib-2.0.so.0 + 0x60872)
                                                  #7  0x00007fb15e69487c n/a (libglib-2.0.so.0 + 0x9787c)
                                                  #8  0x00007fb15e0969cb n/a (libc.so.6 + 0x969cb)
                                                  #9  0x00007fb15e11aa0c n/a (libc.so.6 + 0x11aa0c)
                                                  
                                                  Stack trace of thread 1896:
                                                  #0  0x00007fb15e09f042 n/a (libc.so.6 + 0x9f042)
                                                  #1  0x00007fb15e0931ac n/a (libc.so.6 + 0x931ac)
                                                  #2  0x00007fb15e0931f4 n/a (libc.so.6 + 0x931f4)
                                                  #3  0x00007fb15e11acf5 epoll_wait (libc.so.6 + 0x11acf5)
                                                  #4  0x00007fb15e7f9430 sd_event_wait (libsystemd.so.0 + 0x45430)
                                                  #5  0x00007fb15e7fa844 sd_event_run (libsystemd.so.0 + 0x46844)
                                                  #6  0x00007fb15e7fa990 sd_event_loop (libsystemd.so.0 + 0x46990)
                                                  #7  0x000055a753d77000 n/a (/usr/bin/gdm + 0x1d000)
                                                  #8  0x00007fb15e69487c n/a (libglib-2.0.so.0 + 0x9787c)
                                                  #9  0x00007fb15e0969cb n/a (libc.so.6 + 0x969cb)
                                                #10 0x00007fb15e11aa0c n/a (libc.so.6 + 0x11aa0c)
                                                  
                                                  Stack trace of thread 1895:
                                                  #0  0x00007fb15e09f042 n/a (libc.so.6 + 0x9f042)
                                                  #1  0x00007fb15e0931ac n/a (libc.so.6 + 0x931ac)
                                                  #2  0x00007fb15e0931f4 n/a (libc.so.6 + 0x931f4)
                                                  #3  0x00007fb15e10da36 ppoll (libc.so.6 + 0x10da36)
                                                  #4  0x00007fb15e65d744 n/a (libglib-2.0.so.0 + 0x60744)
                                                  #5  0x00007fb15e65d9d7 g_main_loop_run (libglib-2.0.so.0 + 0x609d7)
                                                  #6  0x00007fb15e545264 n/a (libgio-2.0.so.0 + 0x11a264)
                                                  #7  0x00007fb15e69487c n/a (libglib-2.0.so.0 + 0x9787c)
                                                  #8  0x00007fb15e0969cb n/a (libc.so.6 + 0x969cb)
                                                  #9  0x00007fb15e11aa0c n/a (libc.so.6 + 0x11aa0c)
                                                  
                                                  Stack trace of thread 1901:
                                                  #0  0x00007fb15e11876d syscall (libc.so.6 + 0x11876d)
                                                  #1  0x00007fb15e68d77e g_cond_wait_until (libglib-2.0.so.0 + 0x9077e)
                                                  #2  0x00007fb15e623197 n/a (libglib-2.0.so.0 + 0x26197)
                                                  #3  0x00007fb15e69629b n/a (libglib-2.0.so.0 + 0x9929b)
                                                  #4  0x00007fb15e69487c n/a (libglib-2.0.so.0 + 0x9787c)
                                                  #5  0x00007fb15e0969cb n/a (libc.so.6 + 0x969cb)
                                                  #6  0x00007fb15e11aa0c n/a (libc.so.6 + 0x11aa0c)
                                                  ELF object binary architecture: AMD x86-64
Sep 23 10:41:54 4AISLT001 systemd[1]: systemd-coredump@7-24577-1903_1904-0.service: Deactivated successfully.
Sep 23 10:41:54 4AISLT001 systemd[1]: gdm.service: Main process exited, code=dumped, status=5/TRAP
Sep 23 10:41:54 4AISLT001 systemd[1]: gdm.service: Failed with result 'core-dump'.
Sep 23 10:41:54 4AISLT001 systemd[1]: gdm.service: Triggering OnFailure= dependencies.
Sep 23 10:41:54 4AISLT001 systemd[1]: gdm.service: Failed to enqueue OnFailure=plymouth-quit.service job, ignoring: Unit plymouth-quit.service not found.
Sep 23 10:41:54 4AISLT001 systemd[1]: gdm.service: Scheduled restart job, restart counter is at 8.

Eventually I found that re-enabling Wayland allowed GDM/GNOME to start, however, I now only have 1 of my 2 external monitors being activated when plugged into the USB-C dock.

Current contents of /etc/gdm/custom.conf (previously the WaylandEnable=false line was uncommented)

# GDM configuration storage

[daemon]
# Uncomment the line below to force the login screen to use Xorg
#WaylandEnable=false

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
#Enable=true

seth · 2025-09-24 15:30:07

previously the WaylandEnable=false line was uncommented

do you still get the backtrace in #2 after that?

For the original problem, https://bbs.archlinux.org/viewtopic.php … 5#p2263655 ?
(You'll have to adjust the service, of course)

Bidski · 2025-09-24 22:42:19

seth wrote:

previously the WaylandEnable=false line was uncommented
do you still get the backtrace in #2 after that?

No stack trace, only the stack trace in relation to drivers/gpu/drm/drm_mode_object.c that was present in #1.

seth wrote:

For the original problem, https://bbs.archlinux.org/viewtopic.php … 5#p2263655 ?

I currently have a 5 seconds delay in gdm.service, this does not appear to have any affect

# /etc/systemd/system/gdm.service.d/override.conf 
[Service]
ExecStartPre=
ExecStartPre=sleep 5

Is it weird that with a USB-C with a USB-C dock and the alt mode that the typec and typec_displayport modules are not being loaded?

Bidski · 2025-09-25 01:01:31

There also appear to be issues with resuming from suspend where the external monitors dont always come back and the dock will have to be unplugged and replugged in order for them to be used again

seth · 2025-09-25 07:56:07

1.

Most of the setup seems to work fine, but the DisplayPort alt mode is flakey. Most boots result in the laptop screen working with the external monitors remaining blank. The keyboard, mouse, and ethernet plugged into the dock all work, just not the monitors. In these instances I can usually swap to a tty and
sudo systemctl restart gdm
and the external monitors will start then become active.

2.

Some boots seem to work fine with all external monitors working, but they wont turn on until after logging in to Gnome.

3.

Other boots will only have the laptop screen and there will be this message in the system logs
usb usb4-port1: Cannot enable. Maybe the USB cable is bad?

1. (and 2.) isn't covered by the delayed GDM start?? GDM /does/ start w/ a 5s delay now?
As for 3, have you checked/replaced the cable?
Does re-plugging it change anything about this (or do you get the same error in "dmesg -W" again)?

The typec modules never load? I suspect this is handled transparently by the dock.

nb. your journal shows that so far you've been running Gnome on X11 which is now no longer an option - you could be running into massive -different- troubles w/ Gnome on wayland and this setup.
Does it currently still occasionally work?
Can you test to only boot the multi-user.target (2nd link below) and run some X11 session from there and how reliably that works resp. what errors you get if and when it fails?

Bidski · 2025-09-25 23:45:10

seth wrote:

1. (and 2.) isn't covered by the delayed GDM start?? GDM /does/ start w/ a 5s delay now?

No, the 5 second delay on GDM appears to have no measurable affect, apart from delaying the start of Gnome by 5 seconds.

GDM and GNOME have always started (apart from post #2), but it has only been reliable on the laptop monitor. I have seen 3 behaviours manifesting

Only the laptop monitor is working. xrandr --listmonitors only shows the 1 monitor
The laptop monitor and 1 external monitor is working. xrandr --listmonitors shows 2 monitors. The second external monitor is plugged in but not detected
The laptop monitor and both external monitors are working. xrandr --listmonitors shows 3 monitors

For the first one, replugging the dock will usually bring up both external monitors. I have only seen the second behaviour once so far and nothing I did would bring up the second external monitor. I haven't tried restarting the gdm service in some time, but I suspect that will still work as well. Reloading the GNOME shell (Alt+F2 + r) does not work to bring the external monitors up - I tried this because of the behaviour of the external monitors not turning on until after login.

It is typical that the external monitors only turn on after logging in to Gnome. So the external monitors remain blank and there is the login screen on the laptop monitor.

After waking the laptop up after suspend the external monitors come back and, because I have one of the external monitors set as the primary display, the login screen is on one of the external monitors. After logging back in though the external monitors appear to freeze for 30 seconds or more before (the login screen is still shown, but the displays are unresponsive). This is not consistent behaviour either though, in some instances the login after suspension is smooth and the screens do not freeze.

seth wrote:

As for 3, have you checked/replaced the cable?

The cable can't be replaced, it is hard-wired into the dock

seth wrote:

Does re-plugging it change anything about this (or do you get the same error in "dmesg -W" again)?

It usually resolves that message

seth wrote:

The typec modules never load? I suspect this is handled transparently by the dock.

They don't load at all. I have tried to force load them (using modprobe and then replugging the dock), and also by loading them as modules in the initramfs, but they don't seem to be used. Both /sys/class/typec and /sys/class/typec_mux are empty and here is the output of lsmod

$ lsmod | grep typec
typec_displayport      24576  0
typec                 114688  1 typec_displayport
thunderbolt           573440  1 typec

seth wrote:

nb. your journal shows that so far you've been running Gnome on X11 which is now no longer an option - you could be running into massive -different- troubles w/ Gnome on wayland and this setup.
Does it currently still occasionally work?
Can you test to only boot the multi-user.target (2nd link below) and run some X11 session from there and how reliably that works resp. what errors you get if and when it fails?

I have been using Wayland since my second comment in this thread where I was getting that stack trace. Reverting to Wayland is the only way I have been able to have a bootable system since then. Everything still works periodically. Today I tried leaving the dock unplugged until I have logged in to Gnome. Plugging the dock in after logging in allowed allowed all external monitors to function correctly.

I will try booting to multi-user.target later and see how that works

seth · 2025-09-26 15:08:37

I have been using Wayland since my second comment in this thread

nb. that xrandr is non-authoritative on wayland.

replugging the dock will usually bring up both external monitors … It usually resolves that message

Does virtually re-plugging the cable help?
https://askubuntu.com/questions/645/how … mmand-line

echo 0 | sudo tee /sys/bus/usb/devices/4-1/authorized; sleep 5; echo 1 | sudo tee/sys/bus/usb/devices/4-1/authorized

or you can also use https://github.com/archlinux/aur/tree/usbreset

Bidski · 2025-09-29 23:10:00

seth wrote:

Does virtually re-plugging the cable help?
https://askubuntu.com/questions/645/how … mmand-line
echo 0 | sudo tee /sys/bus/usb/devices/4-1/authorized; sleep 5; echo 1 | sudo tee/sys/bus/usb/devices/4-1/authorized
or you can also use https://github.com/archlinux/aur/tree/usbreset

Either method appears to do nothing

seth wrote:

Can you test to only boot the multi-user.target (2nd link below) and run some X11 session from there and how reliably that works resp. what errors you get if and when it fails?

I booted into multi-user.target using the kernel command line method. After installing xterm, xorg-xclock, and xorg-twm (packages that I was missing), I ran startx but I only had the laptop monitor active. After replugging the dock I still only had the laptop monitor. xrandr --lilstmonitors also only listed the one monitor

journalctl for the multi-user.target boot http://0x0.st/KBnT.txt

I have also noticed that if I leave the dock unplugged until the Gnome login screen appears on the laptop screen, and then plug the dock in then the external monitors appear to always work (2 or 3 boots with this method so far). journalctl for a boot using this method http://0x0.st/KBnm.txt

seth · 2025-09-30 18:08:38

I only had the laptop monitor active. After replugging the dock I still only had the laptop monitor. xrandr --lilstmonitors also only listed the one monitor

"xrandr --listmonitors" will not show disabled outputs, you'd have to check "xrandr -q", also the bare bones X11 session won't run anything like autorandr or x-on-resize to setup outputs
You can expect them all to activate when starting X11, but not when (re)plugging them during the session. You'd have to explicitly eg. "xrandr --output <some output name> --auto".

There're no "usb usb4-port1: Cannot enable. Maybe the USB cable is bad?" messages in either journal.

Bidski · 2025-10-02 22:42:36

seth wrote:

I only had the laptop monitor active. After replugging the dock I still only had the laptop monitor. xrandr --lilstmonitors also only listed the one monitor
"xrandr --listmonitors" will not show disabled outputs, you'd have to check "xrandr -q", also the bare bones X11 session won't run anything like autorandr or x-on-resize to setup outputs
You can expect them all to activate when starting X11, but not when (re)plugging them during the session. You'd have to explicitly eg. "xrandr --output <some output name> --auto".

Unfortunately, I haven't managed to try running any X sessions again, I hope to have some time to try that again later today.

seth wrote:

There're no "usb usb4-port1: Cannot enable. Maybe the USB cable is bad?" messages in either journal.

I tend to associate these messages with drivers/modules not loading correctly for the dock. My suspicion is that some mode change is happening in the dock and the correct module to handle that isn't being loaded, but I have no idea what/how/why.

One thing I have noticed frequently in the journals is this stack trace, I noticed it again just now, it appeared after the dock had been plugged in and just as the external monitors were detected (there was a lengthy delay between the two events so I know it didnt happen when the dock was plugged in). Im not quite sure what to make of this though, the external monitors are operating fine, so it doesn't appear to be a fatal error for the monitors

Oct 03 08:34:08 4AISLT001 kernel: ------------[ cut here ]------------
Oct 03 08:34:08 4AISLT001 kernel: WARNING: CPU: 7 PID: 387 at drivers/gpu/drm/drm_mode_object.c:45 drm_mode_object_add+0x7a/0x80
Oct 03 08:34:08 4AISLT001 kernel: Modules linked in: r8153_ecm cdc_ether usbnet uas usb_storage r8152 mii snd_seq_dummy snd_hrtimer snd_seq rfcomm snd_seq_device xt_conntrack xt_MASQUERADE bridge stp llc ip6table_nat ip6table_filter ip6_tables xt_set ip_set iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter xfrm_user xfrm_algo nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm ib_core cifs_md4 dns_resolver netfs cmac algif_hash algif_skcipher af_alg overlay bnep vfat fat snd_sof_pci_intel_mtl snd_sof_intel_hda_generic soundwire_intel snd_sof_intel_hda_sdw_bpt snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink snd_sof_intel_hda soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi_intel_sdca_quirks soundwire_generic_allocation snd_soc_acpi soundwire_bus snd_soc_sdca snd_hda_codec_realtek snd_soc_core iwlmld intel_uncore_frequency snd_hda_codec_generic intel_uncore_frequency_common intel_pmc_core
Oct 03 08:34:08 4AISLT001 kernel:  snd_hda_scodec_component snd_compress x86_pkg_temp_thermal ac97_bus intel_powerclamp snd_hda_codec_hdmi mac80211 snd_pcm_dmaengine crc8 joydev coretemp mousedev snd_hda_intel libarc4 snd_intel_dspcfg kvm_intel uvcvideo ptp snd_intel_sdw_acpi pps_core videobuf2_vmalloc snd_hda_codec btusb kvm uvc processor_thermal_device_pci iwlwifi btrtl snd_hda_core videobuf2_memops processor_thermal_device r8169 hid_multitouch btintel videobuf2_v4l2 snd_hwdep processor_thermal_wt_hint videobuf2_common platform_temperature_control irqbypass iTCO_wdt snd_pcm realtek btbcm processor_thermal_rfim intel_pmc_bxt rapl cfg80211 videodev intel_rapl_msr intel_cstate mei_gsc_proxy snd_timer spd5118 spi_nor mdio_devres iTCO_vendor_support btmtk processor_thermal_rapl bluetooth intel_uncore mc snd intel_rapl_common wmi_bmof libphy mei_me rfkill i2c_i801 mtd pcspkr pmt_telemetry soundcore intel_lpss_pci i2c_smbus processor_thermal_wt_req mei mdio_bus intel_lpss processor_thermal_power_floor i2c_hid_acpi i2c_mux pmt_class intel_vpu
Oct 03 08:34:08 4AISLT001 kernel:  idma64 intel_pmc_ssram_telemetry processor_thermal_mbox i2c_hid int3403_thermal int340x_thermal_zone intel_hid int3400_thermal acpi_pad pinctrl_meteorlake pinctrl_meteorpoint acpi_thermal_rel sparse_keymap mac_hid crypto_user loop nfnetlink ip_tables x_tables xe drm_suballoc_helper gpu_sched nvidia_uvm(OE) drm_gpuvm drm_exec drm_gpusvm dm_crypt encrypted_keys trusted asn1_encoder tee nvidia_drm(OE) nvidia_modeset(OE) dm_mod nvidia(OE) nvme polyval_clmulni ghash_clmulni_intel nvme_core sha512_ssse3 sha1_ssse3 nvme_keyring spi_intel_pci aesni_intel nvme_auth spi_intel drm_ttm_helper intel_vsec serio_raw i915 i2c_algo_bit drm_buddy mxm_wmi video wmi ttm intel_gtt drm_display_helper cec
Oct 03 08:34:08 4AISLT001 kernel: CPU: 7 UID: 0 PID: 387 Comm: nvidia-modeset/ Tainted: G     U     OE       6.16.8-arch3-1 #1 PREEMPT(full)  c3805c1210d56bc7a68d560dd9e968bb1cc9c38e
Oct 03 08:34:08 4AISLT001 kernel: Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Oct 03 08:34:08 4AISLT001 kernel: Hardware name: Metabox Alpha-VX V360WNNQ/V3xxWNPQ_WNNQ_WNMQ, BIOS 1.07.02TMB 05/02/2025
Oct 03 08:34:08 4AISLT001 kernel: RIP: 0010:drm_mode_object_add+0x7a/0x80
Oct 03 08:34:08 4AISLT001 kernel: Code: c0 78 07 89 45 00 44 89 6d 04 4c 89 e7 e8 ee 34 51 00 31 c0 85 db 0f 4e c3 5b 5d 41 5c 41 5d c3 cc cc cc cc 80 7f 60 00 74 a8 <0f> 0b eb a4 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
Oct 03 08:34:08 4AISLT001 kernel: RSP: 0018:ffffd4f1c2a27ce0 EFLAGS: 00010202
Oct 03 08:34:08 4AISLT001 kernel: RAX: ffffffffc0f8dbc0 RBX: ffff8e1c41de3000 RCX: 0000000000000002
Oct 03 08:34:08 4AISLT001 kernel: RDX: 00000000e0e0e0e0 RSI: ffff8e1cadd252e8 RDI: ffff8e1c41de3000
Oct 03 08:34:08 4AISLT001 kernel: RBP: ffff8e1cadd252e8 R08: 0000000000000000 R09: ffffd4f1c2a27d50
Oct 03 08:34:08 4AISLT001 kernel: R10: ffff8e1cadd252c0 R11: fffffc99c675df00 R12: 0000000000000000
Oct 03 08:34:08 4AISLT001 kernel: R13: 00000000e0e0e0e0 R14: ffff8e1cadd252d0 R15: 000000000000000f
Oct 03 08:34:08 4AISLT001 kernel: FS:  0000000000000000(0000) GS:ffff8e2bdb6da000(0000) knlGS:0000000000000000
Oct 03 08:34:08 4AISLT001 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 03 08:34:08 4AISLT001 kernel: CR2: 00003fa4039a0010 CR3: 00000004ec424002 CR4: 0000000000f72ef0
Oct 03 08:34:08 4AISLT001 kernel: PKRU: 55555554
Oct 03 08:34:08 4AISLT001 kernel: Call Trace:
Oct 03 08:34:08 4AISLT001 kernel:  <TASK>
Oct 03 08:34:08 4AISLT001 kernel:  __drm_encoder_init+0x43/0x140
Oct 03 08:34:08 4AISLT001 kernel:  drm_encoder_init+0x56/0x80
Oct 03 08:34:08 4AISLT001 kernel:  nv_drm_add_encoder+0x178/0x300 [nvidia_drm b984209e136d1f20eaec711162264f33c3289b64]
Oct 03 08:34:08 4AISLT001 kernel:  ? __pfx__main_loop+0x10/0x10 [nvidia_modeset 4d465ba03c7fd486d12e83196b99b579c70b5a03]
Oct 03 08:34:08 4AISLT001 kernel:  nv_drm_handle_dynamic_display_connected+0x64/0xb0 [nvidia_drm b984209e136d1f20eaec711162264f33c3289b64]
Oct 03 08:34:08 4AISLT001 kernel:  nv_drm_event_callback+0x68/0x90 [nvidia_drm b984209e136d1f20eaec711162264f33c3289b64]
Oct 03 08:34:08 4AISLT001 kernel:  nvKmsKapiHandleEventQueueChange+0xb3/0xf0 [nvidia_modeset 4d465ba03c7fd486d12e83196b99b579c70b5a03]
Oct 03 08:34:08 4AISLT001 kernel:  _main_loop+0x90/0x150 [nvidia_modeset 4d465ba03c7fd486d12e83196b99b579c70b5a03]
Oct 03 08:34:08 4AISLT001 kernel:  ? __pfx__main_loop+0x10/0x10 [nvidia_modeset 4d465ba03c7fd486d12e83196b99b579c70b5a03]
Oct 03 08:34:08 4AISLT001 kernel:  kthread+0xf9/0x240
Oct 03 08:34:08 4AISLT001 kernel:  ? __pfx_kthread+0x10/0x10
Oct 03 08:34:08 4AISLT001 kernel:  ret_from_fork+0x1c1/0x1f0
Oct 03 08:34:08 4AISLT001 kernel:  ? __pfx_kthread+0x10/0x10
Oct 03 08:34:08 4AISLT001 kernel:  ret_from_fork_asm+0x1a/0x30
Oct 03 08:34:08 4AISLT001 kernel:  </TASK>
Oct 03 08:34:08 4AISLT001 kernel: ---[ end trace 0000000000000000 ]---

seth · 2025-10-05 21:39:40

https://archlinux.org/packages/extra/x8 … odeswitch/ but I'm not sure about that.
The xorg log will tell us which output is wired where, but

Sep 30 08:53:01 archlinux kernel: [drm:nv_drm_dev_load [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to add connector for NvKmsKapiDisplay 0x00000400
Sep 30 08:53:11 archlinux kernel: [drm:nv_drm_dev_load [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to get dynamic displays
Sep 30 08:53:13 archlinux kernel: nvidia 0000:01:00.0: Enabling HDA controller
Sep 30 08:53:15 archlinux kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 0
Sep 30 08:53:15 archlinux kernel: nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes

Iirc some asus or lenovo systems toggle the GPU when you connect AC (what the dock might provide/be interpreted as - does "acpi -a" suggest that the AC is online when plugging the dock?
Can you completely disable the nvidia GPU in the UEFI and see whether that has any impact on the dock situation?

Alternatively try https://wiki.archlinux.org/title/NVIDIA … ersistence and whether that allows the dock to properly connect or run "prime-run glxgears" before connecting it (assuming that the nvidia GPU becomes the crtc for the dock outputs)

Arch Linux

#1 2025-09-17 23:18:39

Issues with USB-C alt mode dock

#2 2025-09-23 23:28:15

Re: Issues with USB-C alt mode dock

#3 2025-09-24 15:30:07

Re: Issues with USB-C alt mode dock

#4 2025-09-24 22:42:19

Re: Issues with USB-C alt mode dock

#5 2025-09-25 01:01:31

Re: Issues with USB-C alt mode dock

#6 2025-09-25 07:56:07

Re: Issues with USB-C alt mode dock

#7 2025-09-25 23:45:10

Re: Issues with USB-C alt mode dock

#8 2025-09-26 15:08:37

Re: Issues with USB-C alt mode dock

#9 2025-09-29 23:10:00

Re: Issues with USB-C alt mode dock

#10 2025-09-30 18:08:38

Re: Issues with USB-C alt mode dock

#11 2025-10-02 22:42:36

Re: Issues with USB-C alt mode dock

#12 2025-10-05 21:39:40

Re: Issues with USB-C alt mode dock

Board footer