You are not logged in.
Hello,
ever since upgrading to the proprietary `nvidia-dkms` version 580.105.08 my desktop computer cannot complete shutdown.
I have a GTX 1060 and an Intel i5 6500 CPU. MSI motherboard, BIOS is up to date.
I customarily shutdown with this command:
$ shutdown -h 0The systemd shutdown sequence completes without any surprises or errors, but the computer is not powered down after the `systemd-journald: Journal stopped` line. The kernel is running, as I can issue the Alt+SysRq+REISUB command to reboot, but weirdly the Alt+SysRq+REISUO sequence (to shutdown instead of rebooting) doesn't work after the systemd shutdown sequence (power button works of course).
I have tried shutting down while being logged only into the VT console (no graphical session) and the issue also occurs.
Now, while being logged in to my graphical session (sway) and issuing the Alt+SysRq+REISUO the machine shuts down (not cleanly of course and the journal has to be replayed on the next boot).
I don't have any nvidia services enabled:
nvidia-hibernate.service disabled disabled
nvidia-persistenced.service disabled disabled
nvidia-powerd.service disabled disabled
nvidia-resume.service disabled disabled
nvidia-suspend-then-hibernate.service disabled disabled
nvidia-suspend.service disabled disabledI'm also usually using a very stripped down linux kernel. The issue occurs on the vanilla `6.17.7.arch1-1` kernel and my custom kernel.
I have confirmed that downgrading:
downgraded libxnvctrl (580.105.08-1 -> 580.95.05-1)
downgraded nvidia-utils (580.105.08-1 -> 580.95.05-1)
downgraded nvidia-dkms (580.105.08-1 -> 580.95.05-1)
downgraded nvidia-settings (580.105.08-1 -> 580.95.05-1)resolves the issue.
I've searched the forums and online, but couldn't find anyone with a similar issue. Is there anyone else affected? I suspect it's PCI power-management related (just a hunch, I'm not an expert in this domain).
Last edited by marcoe (2025-11-10 22:30:05)
Offline
There're multiple reports about the version breaking HDMI (capping at HDMI 1.2) but the shutdown failure is new.
Does this also happen when shutting down from the multi-user.target and w/ "systemctl poweroff"?
Can you "shutdown -r" (reboot)?
Online
Interesting, I have isolated the issue to occurring after starting the graphical session (sway only for now - will try with other compositors shortly), and now no matter whether I try rebooting or shutting down from the graphical session, or from the VT console AFTER killing the graphical session (`pkill sway`) the machine can't properly reboot/shutdown. But, after trying rebooting/shutting down directly from the multi-user target (sway hasn't been started at all) the reboot/shutdown completes - it seems as if sway puts the driver into some state which prevents the machine from rebooting/shutting down...
Also of note, I use Display Port and don't have resolution/modeline issues.
EDIT: I have tried the niri compositor and can reboot/shutdown. What is sway doing?! I will have some bisection fun going. It occurs on the latest master and the Arch Linux shipped sway (1:1.11-1).
The issue occurs on both the OpenGL and Vulkan sway backends. Sway 1.10.1 with wlroots 1.18.1 also exhibits this issue.
I have tried river, also a wlroots compositor, and the reboot/shutdown works as expected there.
Last edited by marcoe (2025-11-11 22:23:09)
Offline
I have a GTX 1060 and an Intel i5 6500 CPU
Is this a hybrid system? Does nvidia-smi report niri to run on the nvidia GPU? Does merely running nvidia-smi prevent the power-off also from the multi-user.target?
Online
Is this a hybrid system? Does nvidia-smi report niri to run on the nvidia GPU? Does merely running nvidia-smi prevent the power-off also from the multi-user.target?
No, the CPU doesn't have an integrated GPU. Everything runs on the nvidia GPU.
Running `nvidia-smi` in multi-user.target does not prevent me from cleanly rebooting/shutting down.
Offline
Do you get this w/ a fresh user/empty sway config?
Online
So I tried a bunch of things and a few stabs in the dark and isolated the issue further to enabling adaptive sync on my monitor with sway from version 1.10 and wlroots 0.18.1 up to the latest master.
The monitor is an iiyama G-Master GB2770QSU-B6. Enabling adaptive sync on niri works as expected and doesn't inhibit shutdown. I have to try the river compositor again to find out whether it's a wlroots issue or whether it's sway specific (the manner in which wlroots is used by sway more specifically).
EDIT: Enabling adaptive sync on both sway and river causes something to inhibit reboot/shutdown. It's most likely a wlroots-nvidia driver interaction bug. Turning adaptive sync on in the sway config or via the `wlr-randr` utility causes the issue, using `wlr-randr` (to turn adaptive sync on) on river also causes the issue and I even got some atomic commit errors while trying it on river on one occasion out of three tries - the nvidia driver crashed and the journal had to be replayed upon the next boot:
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0Last edited by marcoe (2025-11-12 00:18:38)
Offline
This is still true?
I have confirmed that downgrading:
downgraded libxnvctrl (580.105.08-1 -> 580.95.05-1) downgraded nvidia-utils (580.105.08-1 -> 580.95.05-1) downgraded nvidia-dkms (580.105.08-1 -> 580.95.05-1) downgraded nvidia-settings (580.105.08-1 -> 580.95.05-1)resolves the issue.
I'd not be surprised if the modeline shenanigans that affected HDMI catch you in a different way, but you might want to bring this up at https://forums.developer.nvidia.com/t/5 … 7?u=n7v321 - there's flickering reported w/ the VRR implememtation of kwin
Online
I have the same problem, maybe in https://bbs.archlinux.org/viewtopic.php?id=310133 .
Offline
Someone has reported a very similar issue on the nvidia forums: https://forums.developer.nvidia.com/t/5 … rks/351504
Offline