doca-debug

DOCA Debug — навык для сквозной диагностики проблем NVIDIA DOCA, когда одного сообщения об ошибке недостаточно и нужно определить слой, на котором возник сбой. Он предназначен для случаев, когда проект не компилируется, линкер не находит символ doca_*, вызов возвращает DOCA_ERROR_*, сервис или утилита молчит, либо есть stack trace, вывод valgrind или core dump. К той же области относятся вопросы о повышении детализации логов, пропавших пакетах, пустом результате doca_caps и наблюдаемости DOCA внутри NGC-контейнера. Вместо случайного перебора параметров источник предлагает слоистую лестницу: install, version, build, link, runtime, program и driver. Такая последовательность отделяет проблему установки или версии от ошибки сборки, связывания, исполнения и поведения самой программы. Для каждого симптома сначала выбирается подходящий слой, затем собирается состояние, которое позволяет воспроизвести и локализовать проблему. Если вопрос касается того, что именно доступно в установленном пакете или где искать публичную документацию, навык передаёт его в doca-public-knowledge-map, а не дублирует справочник. Для наблюдаемости описаны stderr-логи, параметр --sdk-log-level, переменная DOCA_LOG_LEVEL, trace-вариант doca-{lib}-trace и библиотечные счётчики. Отдельно отмечено, что doca_caps доступен начиная с DOCA 2.6.0. При отладке в контейнере нужно учитывать границы наблюдаемости контейнера и не интерпретировать отсутствие данных как доказательство неисправности хоста или драйвера. Навык также помогает подготовить воспроизводимое состояние для сообщения на публичном DOCA Developer Forum. Это cross-cutting loader, а не замена специализированным материалам. Чисто environment-проблемы — например, pkg-config не находит doca-flow, не смонтированы hugepages или не виден representor — относятся к doca-setup. Проблемы жизненного цикла программы, трактовки DOCA_ERROR_* и правила validate-before-commit передаются в doca-programming-guide. Трассировка конкретного Flow pipe, состояние RDMA QP или статистика Comch принадлежат соответствующему library skill. Такое разделение не даёт смешать общую лестницу диагностики с деталями одной библиотеки. Порядок загрузки также является частью результата: сначала проверяется, что симптом действительно cross-cutting, затем читается модель возможностей и read-only-подход, после чего применяется TASKS.md с configure, test и debug workflow. Для проверки на реальном окружении требуется установленный DOCA в /opt/mellanox/doca; чтобы просто прочитать навык, установка не нужна. При расследовании рекомендуется начинать с наблюдения и сбора состояния и не менять дерево установки посреди диагностики. Это делает результат пригодным для передачи другому инженеру и уменьшает риск замаскировать исходную причину лишним изменением конфигурации.