Check L40 GPU Health on Ubuntu GPU Servers (2026 Guide) banner image

Check L40 GPU Health on Ubuntu GPU Servers (2026 Guide)

Run a complete NVIDIA L40 GPU health diagnostic on Ubuntu servers. This guide provides copy-paste commands to verify driver status, VRAM integrity, ECC error counts, and CUDA accessibility with machine-parseable output for automated workflows.

GPU
NVIDIA
L40
Ubuntu
Diagnostics
CUDA
⚡ MCP AGENT SHORTCUT

This entire health check process is available as a tested, machine-readable recipe in the Massed Compute MCP. Connect an AI agent and say “Check L40 GPU health on my Ubuntu server” to run all verification steps automatically.

The NVIDIA L40 is a 48GB VRAM datacenter GPU commonly used for AI training and inference workloads. Before deploying any GPU-accelerated application, you should verify the hardware is detected, drivers are loaded correctly, and CUDA is accessible.

This diagnostic workflow provides a systematic approach to validate L40 GPU health with read-only commands that won’t interfere with running workloads. Each step outputs machine-parseable results that can be integrated into automated deployment pipelines.

Required Stack
Component Requirement Notes
Operating System Ubuntu 24.04 LTS Other versions may work but commands are tested on 24.04
GPU Hardware NVIDIA L40 (48GB) PCIe passthrough configured if running in VM
NVIDIA Driver 580.x or newer Must be installed and loaded before running checks
Access Level SSH + sudo sudo only required for kernel log inspection
Minimum Requirements
Resource Minimum Recommended
vCPU 2 cores 6+ cores for GPU workloads
System RAM 8 GiB 32+ GiB for ML frameworks
Storage 256 GB 500+ GB for model storage
Network 1 Gbps 10+ Gbps for distributed training

Massed Compute VM Pricing

Current pricing for GPU instances that meet the L40 health check requirements:

Pricing fetched from the Massed Compute inventory API on July 10, 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 10
gpu_1x_a6000_low_ram 1x RTX A6000 (48GB) [ALT Config] 6 32 GiB 256 GB $0.55/hr 10
gpu_1x_a6000 1x RTX A6000 (48GB) 6 48 GiB 256 GB $0.57/hr 3
gpu_1x_a6000_high_ram 1x RTX A6000 (48GB) [Premium] 6 96 GiB 300 GB $0.57/hr 1
Note: L40 instances are not currently showing available capacity in this snapshot. Check live inventory at vm.massedcompute.com/pricing for current L40 availability and pricing.

Step-by-Step Health Check

1

Connect and Run Preflight Checks

SSH to your L40 host and verify basic system readiness before running the full diagnostic suite:

ssh YOUR_L40_HOST

# Confirm correct host
hostname

# Check nvidia-smi binary exists
command -v nvidia-smi

# Verify nvidia kernel module is loaded
lsmod | grep -E '^nvidia '

# Test PCIe bus accessibility
lspci >/dev/null && echo OK

If the nvidia-smi check or kernel module check fails, the driver is not installed or loaded. Address driver issues before continuing with the health check.

2

Visual Driver and GPU Summary

Get a human-readable overview of the GPU status and driver version:

nvidia-smi

Expected output should show:

  • NVIDIA L40 in the GPU name field
  • Driver Version: 580.x or newer
  • CUDA Version: 12.x or 13.x
  • Memory approximately 49140 MiB total
  • ECC column showing N/A or 0
  • Idle temperature 30-50°C, power 15-40W
3

Machine-Parseable GPU Snapshot

Generate a CSV line with key metrics for automated validation:

nvidia-smi --query-gpu=name,driver_version,memory.total,memory.free,utilization.gpu,temperature.gpu,ecc.errors.uncorrected.volatile.total --format=csv,noheader,nounits

Expected CSV format:

NVIDIA L40, 580.65.06, 49140, ~49100, 0, 38, 0

Critical pass criteria:

  • Field 1: NVIDIA L40
  • Field 2: Driver version matching \d+\.\d+\.\d+
  • Field 3: Memory total = 49140 MiB
  • Field 7: ECC uncorrectable errors = 0 (non-zero is hardware fault)
4

PCIe Device Detection

Confirm the L40 is visible on the PCIe bus:

lspci | grep -i nvidia

Expected: At least one line containing NVIDIA Corporation AD102GL [L40]. Device class typically shows as 3D controller on headless rental servers.

5

Device Node Verification

Check that all required NVIDIA device files are present:

ls /dev/nvidia*

Required device nodes:

  • /dev/nvidia0 – Primary GPU device
  • /dev/nvidiactl – Control device
  • /dev/nvidia-uvm – Unified Virtual Memory
  • /dev/nvidia-uvm-tools – UVM debugging
  • /dev/nvidia-caps/ – Capabilities directory
Important: If /dev/nvidia0 exists but /dev/nvidia-uvm* devices are missing, CUDA applications will fail despite nvidia-smi working correctly.
6

Kernel Ring Buffer Analysis

Inspect kernel logs for GPU-related errors or warnings:

sudo dmesg | grep -iE "nvidia|nvrm|GPU" | tail -50

Expected: NVRM: messages showing successful driver load, GPU UUID assignment, and BAR memory mappings.

Look for these problem indicators:

  • Xid error lines – hardware or driver faults
  • fallen off the bus – PCIe communication failure
  • RmInitAdapter failed – GPU initialization failure
  • Uncorrectable ECC error – memory corruption

Benign messages (not failures):

  • nvidia: loading out-of-tree module taints kernel
  • nvidia: module verification failed
  • [drm] No compatible format found (headless systems)
7

Optional CUDA Smoke Test

Test CUDA accessibility through PyTorch (skip if PyTorch not installed):

python3 -c "import torch; assert torch.cuda.is_available(); assert 'L40' in torch.cuda.get_device_name(0); print('OK')" 2>/dev/null || echo "no torch env (optional)"

Expected: Prints OK if PyTorch is installed and CUDA is accessible. If ModuleNotFoundError occurs, mark this step as n/a – the health check is still valid.

Troubleshooting Common Issues

PCIe Detection Problems

Issue: lspci does not list any NVIDIA device

Cause: GPU not physically attached to VM or PCIe passthrough misconfigured

Solution: Contact your cloud provider – this requires hardware-level configuration changes

Driver Not Loaded

Issue: lspci shows L40 but /dev/nvidia* device nodes are missing

Cause: NVIDIA driver not installed or kernel module not loaded after kernel upgrade

Solution: Install or reinstall NVIDIA drivers, then reboot

ECC Memory Errors

Issue: ecc.errors.uncorrected.volatile.total > 0 in the CSV output

Cause: VRAM memory cells are failing – hardware fault

Solution: Stop all GPU workloads immediately. Save the CSV evidence. Contact provider for GPU replacement. Do not attempt to continue using the faulty GPU.

CUDA Version Mismatch

Issue: PyTorch test fails with “CUDA driver version is insufficient”

Cause: PyTorch wheel built against newer CUDA than driver supports

Solution: Install PyTorch wheel compatible with your driver’s CUDA version, or upgrade the NVIDIA driver

GPU Overheating

Issue: Idle temperature exceeds 90°C with 0% GPU utilization

Cause: Cooling system failure or broken temperature sensor

Solution: Hardware issue requiring provider intervention – do not run workloads on overheating GPU

Skip All of This: Deploy with an AI Agent

This entire L40 GPU health check workflow exists as a tested, machine-readable recipe in the Massed Compute MCP. Instead of running each diagnostic step manually, connect an AI agent and let it execute the complete verification process automatically.

Add this MCP server configuration to your AI client:

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

Then say:

“Check L40 GPU health on my Ubuntu server at 198.51.100.42. Run all diagnostic steps and report any failures with the exact command output.”

The agent will match your request against the recipe catalog, provision the right VM shape if needed, execute all seven health check steps above, and report back with pass/fail results. If any step fails, the agent stops immediately and provides the exact error output for troubleshooting. This recipe was tested and validated on June 10, 2026.

Ready to Deploy L40 Workloads?

Get GPU compute that just works. Launch L40 instances with pre-installed drivers and CUDA toolkit in under 2 minutes.

Think it. Build it. Scale it.

Quick Setup Guide

For teams running this health check repeatedly, create a simple script to automate the process:

#!/bin/bash
# l40-health-check.sh

echo "=== L40 GPU Health Check ==="
echo "Host: $(hostname)"
echo "Date: $(date)"
echo

echo "1. Driver and GPU Summary:"
nvidia-smi
echo

echo "2. Machine-readable snapshot:"
nvidia-smi --query-gpu=name,driver_version,memory.total,memory.free,utilization.gpu,temperature.gpu,ecc.errors.uncorrected.volatile.total --format=csv,noheader,nounits
echo

echo "3. PCIe detection:"
lspci | grep -i nvidia
echo

echo "4. Device nodes:"
ls /dev/nvidia* 2>/dev/null || echo "No nvidia device nodes found"
echo

echo "5. CUDA smoke test:"
python3 -c "import torch; assert torch.cuda.is_available(); assert 'L40' in torch.cuda.get_device_name(0); print('CUDA OK')" 2>/dev/null || echo "CUDA test skipped (no torch)"
echo

echo "=== Health Check Complete ==="

Make it executable and run:

chmod +x l40-health-check.sh
./l40-health-check.sh

Frequently Asked Questions

01How long does the complete health check take?

The entire diagnostic process takes approximately 5 minutes on a healthy L40 system. Most time is spent on the visual nvidia-smi output and optional CUDA test. The machine-parseable checks complete in under 30 seconds.

02Can I run this health check on a GPU that’s actively training a model?

Yes, all commands in this health check are read-only and will not interfere with running workloads. The checks only query GPU status and don’t modify any settings or consume significant GPU resources.

03What should I do if ECC errors are detected?

Stop all GPU workloads immediately if uncorrectable ECC errors are found. Save the CSV output as evidence and contact your provider for hardware replacement. Do not attempt to reset or continue using a GPU with memory errors – this can cause data corruption.

04Why does the health check require sudo access?

Sudo is only needed for the kernel log inspection step (dmesg) to check for hardware errors and driver warnings. All other diagnostic steps run with regular user privileges. If sudo is unavailable, skip the dmesg step and note it in your health report.

05How often should I run L40 health checks in production?

Run a full health check after every system reboot, kernel upgrade, or driver update. For production workloads, consider automated daily checks of the machine-parseable metrics to detect degradation early. Weekly full diagnostics help catch issues before they cause workload failures.