Summary
After the OTA update to DGX OS 7.5.0 (kernel 6.17.0-1032-nvidia, driver 580.173.02), the unit produced no display output on any port (HDMI and USB-C/DP both dead) — warm reboots did not recover. Root cause turned out to be an interaction between the update and NVIDIA’s own package nvidia-drm-options-modeset0 (from repo.download.nvidia.com/baseos, “Override nvidia-drm modeset to 0 for system compatibility”), which was installed on this unit since July and was harmless on the pre-update stack.
With options nvidia-drm modeset=0 in effect under driver 580.173.02:
- No DRM connectors are registered at all (
/sys/class/drmcontains only the card node + render node; Xorg logsNo enabled display devices foundand sets a NULL mode). - USB-C DisplayPort alt-mode never negotiates — a direct USB-C→DP cable produces zero hotplug events on any port (the GPU never even detects the display), and a Thunderbolt hub enumerates in USB fallback mode only (its USB hubs / 2.5GbE / audio all work) but never carries video. USB data on the same ports works fine.
- HDMI works only through the legacy X11 path and negotiates a broken 3840x2160@30 timing that the monitor (Hisense 32GX) cannot lock — “no signal”. 4K@60 and 1080p@60 work when forced manually.
- No framebuffer console (
/proc/fbempty) — the screen shows nothing between the UEFI logo and the (never-appearing) desktop, so there are no boot messages or clues on screen, making this very hard to diagnose without SSH access.
Resolution (confirmed working)
- Remove the override:
sudo apt purge nvidia-drm-options-modeset0(or delete/etc/modprobe.d/zz-nvidia-drm-override.conf), reboot. - Full AC power cycle (unplug PSU ~1 min) to reset the GPU display engine, and power-cycle the Thunderbolt hub as well (it had latched a no-video state and recovered only after a power cycle).
After that: KMS active, DRM connectors present (card1-HDMI-A-1 + 4 USB-C/DP), GNOME session switches to Wayland, framebuffer console works, HDMI fine, and USB-C DP alt-mode functional again — display through the Thunderbolt hub is back at 3840x2160@160Hz.
Why this needs a fix on NVIDIA’s side
- The package is shipped by NVIDIA and was compatible with the pre-update driver (580.95.05 + kernel 6.11): USB-C DP and HDMI both worked with modeset=0 for months.
- Driver 580.173.02 silently changed the contract: USB-C DP alt-mode apparently now depends on nvidia-drm KMS being enabled, and nothing warns about it.
- The OTA updater does not detect or flag this installed-and-now-fatal configuration. Systems with the package installed brick their display path on update (recoverable only via SSH).
- Suggestion: make the 580.173+ driver packages declare
Conflicts: nvidia-drm-options-modeset0, or have the OTA process warn/abort, or gracefully ignore modeset=0 for the USB-C display path.
Environment
- DGX Spark (GB10), BIOS 5.36_0ACUM018, DGX OS 7.2.3 → OTA 7.5.0 (dgx-spark-ota-update-meta 26.03.1 at the time of breakage; fix verified on 26.04.1)
- kernel 6.17.0-1032-nvidia, nvidia-driver-580-open 580.173.02, GSP firmware 580.173.02
- Display: Hisense 32GX 4K via Thunderbolt hub (Intel 8087:5787) downstream TB/DP port; also tested direct USB-C→DP and direct HDMI
Side observations (possibly unrelated)
- During the broken state, warm reboots consistently failed to re-initialize display output; only a full AC power cycle did. Suggest checking GSP display-engine state across warm reboots.
- On HDMI, 3840x2160@30 (the monitor’s EDID-preferred mode) never synced while KMS was disabled — the monitor reported “no signal” while the driver believed the mode was set; 4K@60 and 1080p@60 worked. Not re-tested after the fix; happy to re-test if useful.
nvidia-bug-report.log.gz attached (note: collected after the fix was applied, since the broken state had no usable console; happy to re-collect in the broken state if useful).
nvidia-bug-report.log.gz (759.5 KB)