No video output, no DRM devices detected, BIOS inaccessible

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

Subject: DGX Spark (P4242) – No video output, no DRM devices detected, Secure Boot blocks driver access

Hello NVIDIA Support Team,

I am experiencing a serious issue with my new NVIDIA DGX Spark (Model: P4242, BIOS 5.36_0ACUM018, OS: DGX Spark 7.2.3, Kernel: 6.11.0-1016-nvidia aarch64).

Summary of the problem:

  • The system boots and is reachable via SSH.

  • There is no video output at any stage (no UEFI/BIOS screen, no bootloader, no Linux console), despite monitor, cable and ports being functional.

  • Linux reports no graphics/display devices at all:

    • ls /sys/class/drm/ returns only: version

    • /dev/dri/ does not exist

  • This indicates that no DRM device or display controller is detected by the kernel.

Additional relevant context:

  • The display previously worked normally.

  • The system itself still boots and works over SSH.

This situation also blocks access to UEFI/BIOS, which makes it impossible to manage settings such as Secure Boot (currently enabled and blocking NVIDIA kernel modules).

From a technical perspective, the absence of any DRM devices strongly suggests either:

  • A hardware failure in the display subsystem (PHY/controller/power rail), or

  • A firmware issue causing the display controller not to enumerate at all.

Could you please advise on:

  1. Whether DGX Spark is expected to enumerate DRM/display devices under Linux in a healthy state.

  2. Whether this symptom is consistent with known hardware failures.

  3. Whether this unit should be handled as an RMA case.

If useful, I can provide further logs (dmesg, full system info, etc.).

Thank you for your support.

Kind regards

2

Sorry to see you are experiencing this. Since you can still remotely access the system. Can you generate and send me an nvidia-bug-report so we can better help you?

3

Thanks for your response. Here is the log nvidia-bug-report.log.gz (206.6 KB)

4

Thank you for the logs, can you also give more details on the display model and how you connect to it? Through HDMI or USB-C, is there any dock or adapter involved, etc.

5

I tried via usb-c plus several docks / display hubs but also direct HDMI connection to two different monitors (Dell & HP) that work with different devices. I also tried with different HDMI cables.

6

Thank you for the info. It looks like your GPU has fallen off the bus and is no longer recognized by your system. Please try unplugging your unit and plug it back in to see if that helps.
Edit: Before opening a ticket for an RMA, can you try updating your system over SSH either through the dashboard or by commandline? OS and Component Update Guide — DGX Spark User Guide

7

The January 10 crash was a GSP firmware stall — not a hardware failure. The nvidia-bug-report shows the full sequence.

Xid 119 — January 10, 18:33:56

GSP RPC timeout after 6s
Function 76 (GSP_RM_CONTROL), sequence 94502
Control data: 0x0000000000809908 0x0000000000000010

RPC history — CPU → GSP:

seq 94501 —  761us  completed
seq 94500 — 1058us  completed
seq 94499 — 1082us  completed
seq 94498 — 1131us  completed
seq 94497 —  727us  completed
seq 94496 — 1749us  completed
seq 94495 — 1066us  completed
seq 94502 — never returned

GSP event history — GSP → CPU before silence:

GSP_LOCKDOWN_NOTICE (alternating 0x0 / 0x1) x 8 entries
The GSP entered a protected state before the RPC timeout fired.

Cascade:

18:34:03 — krcWatchdog: GPU likely locked (fires every ~16s)
18:34:09 — Xid 119 seq 94503 — second timeout (0x20800a6a)
18:34:15 — Xid 119 seq 94504 — gnome-shell FREE call timeout
Back to back GSP RPC timeout detected
GPU marked for reset @ kernel_gsp.c:2366
GspRmFree failed hObject=0xbeef0403 status=0x00000065
18:34:47 — Xid 154 — GPU reset required
18:34:47+ — krcWatchdog continues for 10+ minutes

The driver correctly detected the stall and attempted recovery. Reset failed because the GSP was already locked, leaving power cycle as the only recovery path.

The January 16 display failure is a separate issue — Secure Boot.

From your original post:

Secure Boot enabled, blocking NVIDIA kernel modules
/dev/dri/ not present

Bug report confirms:

Kernel is locked down from EFI Secure Boot mode
Failed to load module "nvidia" (module does not exist, 0)

No NVIDIA module → no DRM devices → no display output. This is not a GPU hardware failure.

The MOK enrollment state was not intact after the January 10 power cycle.

Fix (SSH)

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
sudo reboot

Enroll the key in the UEFI MOK manager on reboot.

If the key is missing:

sudo update-secureboot-policy --enroll-key

The GSP stall pattern matches behavior observed across Ampere, Ada, and Blackwell — routine GSP_RM_CONTROL calls complete normally until one never returns, leading to timeout and escalation. This occurred during normal desktop activity with gnome-shell, not under compute load.

Full analysis from primary source evidence: [Root Cause Analysis] DGX Spark driver failure — kernel 6.17.0-1008-nvidia aarch64 panics cause DOE mailbox failure (pstore evidence)