В этом материале
Номер Xid — отправная точка; для диагностики нужны предшествующие события, идентификатор GPU и история восстановления.
Код ошибки существует внутри последовательности
Сообщение Xid помогает начать исследование инцидента GPU, но скриншот одного номера является слабым техническим отчётом. Первое событие устройства, последующие последствия и сообщения восстановления могут относиться к одной последовательности. Если читать только последнюю строку, легко поменять местами предполагаемую причину и следствие отказа.
В руководстве NVIDIA по работе с ошибками Xid описан процесс диагностики. Его применяют с учётом конкретного события и программного стека. Отдельный код нельзя превращать в универсальное заключение о том, что обязательно неисправна плата, приложение или установленный драйвер.
Сохраняйте время и идентификаторы
Соберите ограниченное окно журналов до события и после него. В запись входят идентификатор загрузки хоста, UUID GPU при доступности, адрес PCI, версия драйвера и исходные сообщения ядра. Индекс ноль не является постоянным идентификатором после перезагрузки или изменения оборудования. В общем отчёте также необходимо различать одинаково пронумерованные устройства разных серверов.
Оставляйте исходный формат времени и способ его привязки сборщиком к UTC. Относительное время ядра и календарное время приложения нельзя молча вычитать друг из друга. Если точность согласования неизвестна, укажите интервал неопределённости вместо придуманного порядка событий разных процессов с точностью до миллисекунды.
Укажите роль каждого события
Сделайте таблицу с временем наблюдения, источником, устройством, сообщением и трактовкой. Интерпретацию отделяйте от оригинального текста. Руководство по анализу каталога Xid даёт контекст конкретных кодов. Рекомендованные действия зависят от события и собранных свидетельств, а не от яркости предупреждения на панели мониторинга.
В условной последовательности могут стоять таймаут приложения, сообщение Xid и перезапуск рабочего процесса. Один такой порядок ещё не доказывает, что таймаут повредил устройство или что перезапуск его восстановил. Сначала нужно установить, относится ли всё к одной GPU и сохранились ли более ранние сообщения системы.
Проверяйте конкурирующие объяснения
Сравните затронутые и незатронутые процессы на одинаковой версии нагрузки. Уточните, совпало ли событие с изменением хоста, развёртыванием, проблемой транспорта или восстановлением оборудования. Сохраните рабочую конфигурацию для сравнения вместо одновременной замены нескольких факторов. Недоступный после инцидента запрос состояния GPU записывайте как недоступный, а не как здоровое нулевое значение.
Если повторяемый тест уместен, заранее задайте условия остановки и храните исходный инцидент отдельно. Успешный последующий прогон уточняет наблюдаемое поведение, но не отменяет предшествующий отказ. Ограниченное исследование не должно незаметно превращаться в неучтённый стресс-тест занятого сервиса.
Подготовьте полезную передачу инцидента
Результат исследования — краткая последовательность событий, исходное окно журналов, сведения об устройстве и ПО, условия нагрузки, выполненные действия восстановления и нерешённые вопросы. Подтверждённые наблюдения нужно отличать от гипотез. Такая запись делает дальнейшую диагностику воспроизводимой без заявления о корневой причине, которую имеющиеся свидетельства пока не позволяют установить.