Useful report — the workaround you’ve described (disable GDM, switch to multi-user.target) is exactly what I landed on after a different but related hang on 580.159.03. A few data points worth adding:
In my case the deadlock was in nvidia / nvidia_uvm rather than nvidia_modeset, and it reproduced after disabling GDM as well — triggered by an NV_ERR_NO_MEMORY from _memdescAllocInternal during a heavy vLLM allocation rather than by display tear-down. The blocked consumers I observed across two separate hangs were a vLLM worker (Wednesday, with Xorg as writer) and nvidia-smi (Thursday, with a vLLM worker as writer) — so the consumers and the writers can be any combination of GUI, CUDA, and management-plane processes; it’s not specific to display teardown.
So the architectural class of “long-held NVIDIA driver lock deadlocks consumers” appears to span at least the modeset and RM/UVM paths, and the GDM-disable workaround removes display-path triggers but not allocation-path triggers.
Setup for comparison:
- 2x DGX Spark
- Driver: 580.159.03 (open kernel modules)
- Kernel: 6.17.0-1018-nvidia
- NCCL: 2.30.6
- vLLM: 0.19.1rc1.dev1315+g102aaddf8.d20260519 (via
eugr/spark-vllm-docker) - Workload: DeepSeek-V4-Flash, TP=2 across nodes,
--gpu-memory-utilization 0.85,--kv-cache-dtype fp8
Cross-linking my post in the other thread for completeness: Help, team spark! - #6 by j0n