doca-debug

Diagnose DOCA build, link, runtime, and driver failures using a layered debug ladder.

3.2k|370|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/NVIDIA/skills --skill doca-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doca-debug
Source: https://github.com/NVIDIA/skills/tree/main/skills/doca-debug
Command: npx skills add https://github.com/NVIDIA/skills --skill doca-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Debugging NVIDIA DOCA applications is hard because symptoms like link errors, silent programs, or DOCA_ERROR_* return codes can originate at any of seven layers (install, version, build, link, runtime, program, driver). This Skill gives agents a canonical layered ladder and a 5-phase iterative debug loop so they identify the correct layer first, capture read-only evidence before mutating anything, and avoid wasted effort.

Core Features & Use Cases

  • 7-layer debug ladder: Classifies any DOCA symptom (install through driver/firmware) and prescribes the exact read-only probes per layer, such as pkg-config --modversion, doca_caps --list-devs, and dmesg.
  • Observability controls: Explains how to raise verbosity with --sdk-log-level, DOCA_LOG_LEVEL, and the doca-<library>-trace build flavor to make hidden state visible.
  • Reproducible capture workflow: Guides capturing the program/system/DOCA triple for forum posts and escalation to the DOCA Developer Forum.
  • Use Case: A developer hits "undefined reference to doca_flow_init" and the agent places the symptom at the Link layer, then prescribes using pkg-config --libs doca-flow verbatim instead of a hand-typed link line.

Quick Start

Ask your agent to help debug a DOCA symptom, for example: my DOCA program fails at the link step with undefined reference to doca_flow_init, walk me through which layer is responsible.

Frequently Asked Questions about doca-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug an undefined reference to doca_* link error?

An undefined reference to a doca_* symbol is a Link-layer (layer 4) failure. Use pkg-config --libs doca-<library> verbatim for the link line instead of hand-typing -l flags, since libraries like DOCA Flow ship as multiple separate shared objects on recent versions.

How do I get more log output from a DOCA program?

Raise verbosity with --sdk-log-level 70 (TRACE) on the first run, or set DOCA_LOG_LEVEL for programs that read it. For deeper output, link against the doca-<library>-trace pkg-config module, which emits DEBUG and TRACE lines the release flavor never produces.

Can I debug DOCA hardware symptoms inside the NGC container?

Container debug is limited: in-container dmesg, journalctl, and /sys show the container's view, not host kernel or hardware events. For symptoms involving real packets or devices, use a native install or a host shell before forming hardware hypotheses.

When should I not use the doca-debug skill?

Route elsewhere for env-class symptoms like pkg-config failures or unmounted hugepages (doca-setup), DOCA_ERROR_* taxonomy and lifecycle interpretation (doca-programming-guide), and library-specific debug such as Flow pipe traces or RDMA queue-pair stats (the matching library skill).

What should I capture before posting to the DOCA Developer Forum?

Capture the read-only triple: program stdout/stderr with --sdk-log-level 70, the system view via dmesg and journalctl, and the DOCA view via doca_caps --list-devs plus pkg-config --modversion. State which ladder layer you reached and avoid internal hostnames or build numbers.