Fix nvidia-smi Issues with NVIDIA GPU on Ubuntu (2026 Guide) banner image

Fix nvidia-smi Issues with NVIDIA GPU on Ubuntu (2026 Guide)

Complete diagnostic and repair guide for nvidia-smi failures on Ubuntu hosts with NVIDIA L40, RTX A6000, and other GPUs. Follow the error lookup table and step-by-step remediation to restore GPU functionality.

GPU NVIDIA Ubuntu Troubleshooting Driver Diagnostics
📋 MCP RECIPE

This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Deploy an AI agent to run these diagnostics and repairs automatically, with approval gates for destructive operations.

GPU workloads fail when nvidia-smi stops working. This guide helps you diagnose and fix common nvidia-smi failures on Ubuntu hosts with NVIDIA GPUs, including driver/library version mismatches, module loading issues, and hardware communication problems.

The diagnostic approach uses an error string lookup table to classify failures before attempting any remediation. This prevents unnecessary module reloads that can kill running CUDA workloads.

Tech Stack
Component Version Purpose
Ubuntu 24.04 LTS Host operating system
NVIDIA Driver Latest stable GPU kernel modules and userspace
nvidia-smi Bundled with driver GPU monitoring and management
NVIDIA L40/A6000 Ada/Hopper architecture Target GPU hardware
Requirements
Requirement Specification
Operating System Ubuntu 24.04 LTS
vCPU Minimum 2 cores
Memory Minimum 8 GB RAM
GPU NVIDIA GPU (any model)
Access SSH with sudo privileges

Massed Compute VM Pricing

Pricing fetched from the Massed Compute inventory API on July 13, 2026.
SKU Description vCPU RAM Storage Price Capacity
gpu_1x_A30 1x A30 (24GB) 16 48 GiB 256 GB $0.35/hr 0
gpu_1x_a5000 1x RTX A5000 (24GB) 10 32 GiB 256 GB $0.44/hr 0
gpu_1x_a6000_spot 1x RTX A6000 (48GB) [Spot] 6 32 GiB 256 GB $0.50/hr 1
gpu_1x_a6000_low_ram 1x RTX A6000 (48GB) [ALT Config] 6 32 GiB 256 GB $0.55/hr 1
gpu_1x_a6000 1x RTX A6000 (48GB) 6 48 GiB 256 GB $0.57/hr 0
gpu_1x_a6000_high_ram 1x RTX A6000 (48GB) [Premium] 6 96 GiB 300 GB $0.57/hr 0

Error String Lookup Table

Before running any commands, match the exact error output from nvidia-smi against this lookup table to determine the appropriate remediation path:

Error Symptom Recommended Action
command not found: nvidia-smi Driver installation or repair needed
Driver/library version mismatch Module reload or reboot
Failed to initialize NVML: Unknown Error Reload nvidia_uvm module only
No devices were found Check PCIe enumeration with lspci
GPU has fallen off the bus Hardware issue – escalate to provider
nvidia-smi hangs indefinitely Module reload required
couldn't communicate with NVIDIA driver Try modprobe nvidia first
ECC Uncorrectable counter > 0 Stop workloads – VRAM degrading

Step-by-Step Deployment

1

Connect to GPU Host

SSH to your GPU-enabled host and capture the failing nvidia-smi output:

ssh YOUR_VM_IP

Save the complete error output to compare against the lookup table above.

2

Run Diagnostic Ladder

Execute this read-only diagnostic sequence to classify the failure without making changes:

echo "=== nvidia-smi attempt ==="
nvidia-smi; echo "exit=$?"

echo "=== userspace presence ==="
which nvidia-smi || echo "MISSING: nvidia-smi not on PATH"
dpkg -l | grep -iE '^ii\s+(nvidia-driver|libnvidia|nvidia-utils)' | awk '{print $2, $3}'

echo "=== kernel modules ==="
lsmod | grep -E '^nvidia' || echo "MISSING: no nvidia modules loaded"

echo "=== recent kernel messages ==="
sudo dmesg -T | grep -iE 'nvidia|nvrm|fallen off the bus|Xid' | tail -50

echo "=== persistence daemon ==="
systemctl status nvidia-persistenced --no-pager | head -10 || true

echo "=== PCIe enumeration ==="
lspci -nn | grep -i nvidia || echo "MISSING: no NVIDIA device on PCIe bus"
3

Check for Active GPU Processes

Identify any processes using the GPU before attempting module operations:

sudo fuser -v /dev/nvidia* 2>/dev/null || true
sudo lsof /dev/nvidia* 2>/dev/null | awk 'NR>1 {print $2, $1, $9}' | sort -u
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv,noheader 2>/dev/null || true

Record all process IDs. Module reload will terminate these processes.

4

Apply Gated Remediation

Based on your error lookup, apply the appropriate fix with increasing invasiveness:

Gate 1: Enable Persistence Mode (Lowest Risk)

sudo nvidia-smi -pm 1
nvidia-smi --query-gpu=persistence_mode --format=csv,noheader
Approval Required: Confirm no other tenant has explicitly disabled persistence on shared hosts.

Gate 2: Full Module Reload (Kills CUDA Work)

# Unload in dependency order
sudo modprobe -r nvidia_uvm nvidia_modeset nvidia_drm nvidia

# Reload (takes 5-15 seconds)
sudo modprobe nvidia
sudo modprobe nvidia_uvm
sudo modprobe nvidia_modeset
sudo modprobe nvidia_drm
Warning: This kills all CUDA processes – training runs, inference servers, containers. Coordinate on multi-tenant hosts.

Gate 3: Reload nvidia_uvm Only

sudo modprobe -r nvidia_uvm
sudo modprobe nvidia_uvm

Gate 4: Restart Persistence Daemon

sudo systemctl restart nvidia-persistenced
systemctl status nvidia-persistenced --no-pager | head -10
5

Verify Repair

Run these verification checks in order. Stop immediately if any fails:

1. Check nvidia-smi functionality:

nvidia-smi --query-gpu=name,driver_version --format=csv,noheader | grep -q "NVIDIA"; echo "result=$?"

2. Verify all kernel modules loaded:

lsmod | grep -E '^nvidia'

3. Check for new Xid errors:

sudo dmesg -T | grep -iE 'nvidia|nvrm|Xid' | tail -10

4. Confirm driver version consistency:

nvidia-smi --query-gpu=driver_version --format=csv,noheader
dpkg -l | grep -E '^ii\s+nvidia-driver' | awk '{print $3}'

Troubleshooting Common Issues

Module Reload Failures

If modprobe -r fails with “Module nvidia is in use” but lsof shows no holders, the driver is wedged. A reboot is required – do not loop on remediation attempts.

Persistence Mode Failures

If nvidia-smi -pm 1 returns “Unable to set persistence mode”, the daemon isn’t running or the driver is broken. Try restarting nvidia-persistenced first, then proceed to module reload if still failing.

Recurring Failures

If nvidia-smi works for minutes then fails again after remediation, this indicates an intermittent hardware fault. Escalate to the provider – do not repeatedly attempt the same fixes.

Hardware Communication Errors

“GPU has fallen off the bus” errors in dmesg indicate hardware or thermal events that persist across power cycles. This requires provider intervention for board inspection. Reboot provides only temporary mitigation.

Memory Corruption

If ECC Uncorrectable counter shows values greater than 0, stop all GPU workloads immediately. Data written to VRAM may already be corrupt. Escalate for board replacement.

Skip All of This: Deploy with an AI Agent

This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Connect an AI agent to automatically run the diagnostic ladder, apply appropriate remediations with approval gates, and report results.

{
  "mcpServers": {
    "massed-compute": {
      "type": "http",
      "url": "https://vm.massedcompute.com/api/mcp",
      "headers": { "Authorization": "Bearer MC_TOKEN" }
    }
  }
}

Then say:

“My nvidia-smi is failing with error ‘Failed to initialize NVML: Driver/library version mismatch’. Please diagnose and fix the GPU driver issues on my Ubuntu host, but ask before any operations that could kill running CUDA workloads.”

The agent matches your request against the recipe catalog, provisions the right diagnostics, runs the error lookup and verification steps above, and reports back with the result. The recipe was tested on June 10, 2026 and includes approval gates to prevent destructive operations without confirmation.

Ready to Deploy GPU Workloads?

Get reliable GPU compute with automatic driver management and 24/7 infrastructure monitoring. Deploy in under 60 seconds.

Think it. Build it. Scale it.

Quick Setup Reference

For rapid deployment of the diagnostic process:

  1. Save error output: Copy the exact nvidia-smi failure message
  2. Match lookup table: Find your error in the table to determine remediation path
  3. Run diagnostics: Execute the read-only diagnostic ladder first
  4. Check processes: Identify any active GPU workloads before module operations
  5. Apply gated fix: Use the least invasive remediation that matches your error
  6. Verify repair: Run all verification checks in sequence

Frequently Asked Questions

01 What should I do if nvidia-smi hangs indefinitely?

A hanging nvidia-smi typically indicates kernel module communication issues. Try a full module reload (Gate 2), but be aware this will kill all running CUDA processes. If the modules are busy and won’t unload, a reboot may be necessary.

02 Can I reload NVIDIA modules without killing running workloads?

No, reloading the nvidia kernel modules will terminate all CUDA processes including training runs, inference servers, and containerized workloads. Use Gate 1 (persistence mode) or Gate 3 (nvidia_uvm only) for less invasive repairs when possible.

03 How do I know if my GPU hardware is failing?

Look for “GPU has fallen off the bus” messages in dmesg, ECC uncorrectable errors greater than 0, recurring Xid errors (especially 79, 13, 31, 63), or nvidia-smi failures that recur within minutes of successful remediation. These indicate hardware issues requiring provider intervention.

04 What’s the difference between driver/library version mismatch and unknown errors?

Driver/library version mismatch occurs when userspace tools don’t match the loaded kernel modules, typically after driver updates. Unknown errors usually indicate communication issues between userspace and kernel, often fixable by reloading just the nvidia_uvm module.

05 Should I reboot if module reload fails?

If modprobe -r fails with “Module nvidia is in use” but no processes show in lsof/fuser output, the driver is wedged and a reboot is the safest option. Don’t repeatedly attempt module operations as this can destabilize the system further.