You are not logged in.
Pages: 1
Hello!
In the past I had several takes on setting up my laptop but I just ended up with turning on my dGPU permanently and leaving it in that state.
But to the point: I have a laptop with intel uhd and nvidia 2080 super mobile.
I need to do the following setup:
- gnome (wayland) should run on iGPU
- nvidia should be powered-off (suspended) as long as I don't run some advanced 3d apps (or some game) or
- I plug my secondary monitor
I followed https://wiki.archlinux.org/title/PRIME# … ntegration
I followed 1.3.1.2. I set up udev and modules. Then I performed recommended checks and...
$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
activebut cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time doesn't increase the timer.
also
[~ (0) ]$ cat /proc/driver/nvidia/gpus/0000:01:00.0/power
Runtime D3 status: Not supportedUnfortunately due to recent nvidia changes I'm unable to install closed source driver to check if disabling GSP
Also, doing lsof +c0 /dev/nvidia* shows that gnome-shell uses nvidia device.
Offline
Unfortunately due to recent nvidia changes I'm unable to install closed source driver to check if disabling GSP
Why? It's a turing chip, no?
https://aur.archlinux.org/packages?O=0&K=580xx
Offline
Hi, sorry I forgot to subscribe and the forum didn't send me an demail ;-)
Let me try nvidia-580xx-dkms and try again. Thank you.
Edit 1
ok, now it works almost perfectly.
The only big problem that I have with this setup is that it ]doesn't work with my external display. By doesn't work I mean that:
- If I boot with the display connected, the display works fine, but when I unplug it, gpu doesn't suspend at all
- when I boot without the display, suspending works, but when I connect the display everything freezes. (gpu goes to the active state, but then it freezes and I need to force-shutdown my laptop)
Last edited by gucio321 (2026-01-17 12:51:05)
Offline
In the second case, can you still switch the VT and/or ssh into the system and does merely restarting the graphical target (gnome/GDM) help?
In the first case, does mutter end up running on the nvidia chip?
What's the output of "glxinfo -B"?
Offline
when it freezes, I can't switch to the operational virtual console (but the system works and I can probably ssh into it but I don't have second device atm so can't check)
For the first case:
[~ (0) ]$ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel (0x8086)
Device: Mesa Intel(R) UHD Graphics (CML GT2) (0x9bc4)
Version: 25.3.3
Accelerated: yes
Video memory: 15759MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics (CML GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.3.3-arch1.2
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.3.3-arch1.2
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.3.3-arch1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20Also, I've tried to `systemctl isolate multi-user.target` and then back `systemctl isolate graphical.target` but it didn't help.
Offline
does mutter end up running on the nvidia chip?
"No"
the system works and I can probably ssh into it but I don't have second device atm
https://wiki.archlinux.org/title/Keyboa … el_(SysRq) + REISUB or even rebooting by frenetically pressing ctrl+alt+del might suffice to get us a useful journal from the previous ("frozen") boot.
Offline
I did a bit more testing, and actually... It not always freezes. I was able to boot without display, plug it and it didn't freez. However, the display still was not detected and after unplugging it my card doesn't go into suspend state.
Here is what journalctl thinks about it:
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0167] dhcp4 (wlp0s20f3): canceled DHCP transaction
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0167] dhcp4 (wlp0s20f3): activation: beginning transaction (timeout in 45 seconds)
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0168] dhcp4 (wlp0s20f3): state changed no lease
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0169] dhcp4 (wlp0s20f3): activation: beginning transaction (timeout in 45 seconds)
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: authenticate with f0:9f:c2:2e:1c:83 (local address=0c:9a:3c:6a:6b:48)
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: send auth to f0:9f:c2:2e:1c:83 (try 1/3)
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0538] device (wlp0s20f3): supplicant interface state: completed -> authenticating
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0539] device (p2p-dev-wlp0s20f3): supplicant management interface state: completed -> authenticating
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:24 IUseArchBTW wpa_supplicant[969]: wlp0s20f3: Trying to associate with f0:9f:c2:2e:1c:83 (SSID='dsalfa' freq=5220 MHz)
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: authenticated
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0833] device (wlp0s20f3): supplicant interface state: authenticating -> associating
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.0834] device (p2p-dev-wlp0s20f3): supplicant management interface state: authenticating -> associating
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: associate with f0:9f:c2:2e:1c:83 (try 1/3)
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: RX ReassocResp from f0:9f:c2:2e:1c:83 (capab=0x1511 status=0 aid=4)
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: associated
Jan 17 18:37:24 IUseArchBTW wpa_supplicant[969]: wlp0s20f3: Associated with f0:9f:c2:2e:1c:83
Jan 17 18:37:24 IUseArchBTW wpa_supplicant[969]: wlp0s20f3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1034] device (wlp0s20f3): supplicant interface state: associating -> associated
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1034] device (p2p-dev-wlp0s20f3): supplicant management interface state: associating -> associated
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1100] device (wlp0s20f3): supplicant interface state: associated -> 4way_handshake
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1100] device (p2p-dev-wlp0s20f3): supplicant management interface state: associated -> 4way_handshake
Jan 17 18:37:24 IUseArchBTW wpa_supplicant[969]: wlp0s20f3: WPA: Key negotiation completed with f0:9f:c2:2e:1c:83 [PTK=CCMP GTK=CCMP]
Jan 17 18:37:24 IUseArchBTW wpa_supplicant[969]: wlp0s20f3: CTRL-EVENT-CONNECTED - Connection to f0:9f:c2:2e:1c:83 completed [id=0 id_str=]
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1289] device (wlp0s20f3): supplicant interface state: 4way_handshake -> completed
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1293] device (wlp0s20f3): ip:dhcp4: restarting
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1408] dhcp4 (wlp0s20f3): canceled DHCP transaction
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1408] dhcp4 (wlp0s20f3): state changed no lease
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1409] dhcp4 (wlp0s20f3): activation: beginning transaction (timeout in 45 seconds)
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1410] device (p2p-dev-wlp0s20f3): supplicant management interface state: 4way_handshake -> completed
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1655] dhcp4 (wlp0s20f3): state changed new lease, address=10.204.51.124, acd pending
Jan 17 18:37:24 IUseArchBTW NetworkManager[860]: <info> [1768671444.1657] dhcp4 (wlp0s20f3): state changed new lease, address=10.204.51.124
Jan 17 18:37:24 IUseArchBTW kernel: wlp0s20f3: Limiting TX power to 23 (23 - 0) dBm as advertised by f0:9f:c2:2e:1c:83
Jan 17 18:37:24 IUseArchBTW systemd[1]: Starting Network Manager Script Dispatcher Service...
Jan 17 18:37:24 IUseArchBTW systemd[1]: Started Network Manager Script Dispatcher Service.
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:24 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:26 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:28 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:28 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:28 IUseArchBTW gnome-shell[2853]: g_closure_add_invalidate_notifier: assertion 'old_flags.flags.n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed
Jan 17 18:37:34 IUseArchBTW systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.Also, let me note that by "plug/unplug my display" I mean plugging/unplugging a usb-c dock with my display connected.
Edit 1
Also, After writing the above, I tried to restart my laptop and noticed another interessting thing

Last edited by gucio321 (2026-01-17 17:46:25)
Offline
I mean plugging/unplugging a usb-c dock with my display connected.
Is this an eGPU??
Boot w/ the dock/monitor connected, dump the output of "nvidia-smi", unplug the dock, run "nvidia-smi" again, then post both outputs and the complete system journal
sudo journalctl -b | curl -F 'file=@-' 0x0.stOffline
journal:
http://0x0.st/PKNJ.txt
Is this an eGPU??
its not an eGPU, my monitor is connected to this dock
Offline
Dock seems to the same chip as https://bbs.archlinux.org/viewtopic.php?id=311706 (but Ugreen CM179 . /. HP USB-C Dock G5)
gnome-shell is and remains attached to the nvidia GPU but
Jan 18 00:09:35 IUseArchBTW gnome-shell[3357]: GPU /dev/dri/card1 selected primary from builtin panel presence runs on the IGP.
But there's a significant drop in power and memory in the GPU in the second nvidia-smi (which however might be coincidental and general post-boot cooldown)
Jan 18 00:09:27 IUseArchBTW kernel: nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
Jan 18 00:09:27 IUseArchBTW kernel: ucsi_ccg 10-0008: i2c_transfer failed -110
Jan 18 00:09:27 IUseArchBTW kernel: ucsi_ccg 10-0008: ucsi_ccg_init failed - -110
Jan 18 00:09:27 IUseArchBTW kernel: ucsi_ccg 10-0008: probe with driver ucsi_ccg failed with error -110Since all problems seem to hinge on the USB dock¹ try to blacklist ucsi_ccg (it's the USB controller on the GPU that's used for VR devices)
¹ Not so sure about the freeze when attaching the dock after the boot, that could just be gnome-shell going while when re-arranging the outputs.
If you can completely disable the GPU that might be an interesting test to see whether it's relevant here at all.
Offline
¹ Not so sure about the freeze when attaching the dock after the boot, that could just be gnome-shell going while when re-arranging the outputs.
I was not able to reproduce this freez so I suppose this was something random.
If you can completely disable the GPU that might be an interesting test to see whether it's relevant here at all.
I think I can blacklist nvidia driver, but then I can't use external monitor at all (usb-C displays are handled by dGPU probably)
Since all problems seem to hinge on the USB dock¹ try to blacklist ucsi_ccg (it's the USB controller on the GPU that's used for VR devices)
ok, will try that now.
Edit 1
I blacklisted it but no change unfortunately.
Also, for more context i did the following:
- boot without dock
- run nvidia-smi
- plug the dock
- nvidia-smi
- exported journal
http://0x0.st/PKuW.txt
http://0x0.st/PKu4.txt (sorry, I confused commands and only the second smi run was saved. I'll rerun later as I have to go now)
Last edited by gucio321 (2026-01-18 18:24:42)
Offline
but then I can't use external monitor at all (usb-C displays are handled by dGPU probably)
Seems so and would explain the nvidia-smi movement.
The GPU still powers down when not using the dock at all?
Does the behavior change w/ not-gnome (other wayland compositor or random X11 session)?
Offline
The GPU still powers down when not using the dock at all?
it does only when booted without the dock. Also this always happens if booted without dock and trying to shut down later:
]
(this is infinite loop. I doesn't shut down. I have to force-off with power btn)
Does the behavior change w/ not-gnome (other wayland compositor or random X11 session)?
I tried with xfce (which didn't start at all for some reason) and plasma on wayland.
Plasma gave the same result.
Last edited by gucio321 (2026-01-18 23:22:47)
Offline
You don't get that when booting w/o the dock?
I tried with xfce (which didn't start at all for some reason)
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
Offline
Hi
sorry I was a bit busy last days.
I've tested xfce again and turns out I installed it incorrectly ;-)
Today I did it the right way, and turns out on xorg, the behaviour is almost exactly the same (with the difference that my external monitor doesn't work at all, but the behavior of envidia is the same)
I used
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_statusEdit 1
I've just noticed something interessting.
Generally speaking - I was wrong while talking about booting without the dock breaks my external monitor detection.
This is the case after nvidia is suspended first time after boot.
So my guess is that there is something wrong with resuming my gpu?
Edit 2
well I did a lot of testing now and the issue becomes more and more strange...
I just noticed that the dock itself impacts the behavior. If I boot with the dock connected and monitor (display port) unplugged it still behaves as if the monitor was connected (gpu remains active).
So I went ahead and took my HDMI to USB-C cable.
Now when I boot with nothing connected, nvidia suspens and I plug in the cable, gnome freezes
however I'm able to get into the console so I'll send logs in a sec.
Just to be clear: I'm doing all of that on gnome+wayland.
Edit 3
Okey here are my logs: https://0x0.st/PPak.txt
Also one more interessting note:
By "gnome freezing" I mean that the mouse cursor still works, but I can't interact with any UI element.
Also When I ran
watch cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_statusand when it freezes it is in "resuming" state.
Last edited by gucio321 (2026-01-21 23:50:09)
Offline
turns out I installed it incorrectly
How and what does the Xorg log of a now misbehaving X11 session look like?
For its location consult, https://wiki.archlinux.org/title/Xorg#General
Offline
Since it just came up in https://bbs.archlinux.org/viewtopic.php … 8#p2284238 - you /do/ set the necessary kernel module parameters, do you?
Offline
Pages: 1