PCIe AER рядом с GPU: severity, requester и хронология

Сообщение PCIe AER рядом с GPU нужно читать по severity, requester identity и месту регистрации в topology. Компонент, напечатавший сообщение, не обязательно является первопричиной. Сохраните полный журнал и хронологию до reset или reboot. Отдельно сопоставьте GPU Xid и ошибки приложения. Одна строка с названием GPU либо Root Port не дает достаточного основания обвинить конкретную карту, кабель, слот или драйвер без проверки контекста события.

Сначала определите severity

Руководство Linux AER различает correctable и uncorrectable события, а среди последних — non-fatal и fatal. Это разные условия интерфейса и восстановления. Не превращайте все сообщения в единый уровень «критическая GPU ошибка», но и не удаляйте повторяющиеся corrected записи из истории до анализа. Сохраните полную классификацию, status/mask и доступные сведения о transaction. Ограничение частоты сообщений также означает, что количество строк журнала не обязательно равно количеству всех аппаратных событий на исследуемом участке шины.

Сопоставьте requester и reporting path

AER передает сведения через PCIe hierarchy, поэтому важно сохранить BDF участников и topology. Requester identity имеет конкретный смысл в отчете и не заменяет расследование root cause. Нарисуйте путь endpoint, switch при наличии и root port. Не делайте вывод, что неисправен именно компонент с адресом в начале строки. Если несколько устройств находятся за одним upstream элементом, их общая реакция требует анализа всей ветви, а не только одной карты, первой замеченной в приложении.

Пример временной карточки

Для учебного инцидента создайте таблицу с событиями AER, GPU Xid, потеря ответа приложения и наблюдаемое восстановление. В каждой строке укажите timestamp, clock source, BDF или GPU identity и исходный текст. Это шаблон, не отчет о случившейся аварии. Порядок строк должен приходить из выровненной временной шкалы. Если часы источников различаются, отмечайте неопределенность вместо точного утверждения, что kernel сообщение на несколько миллисекунд предшествовало отказу модели и поэтому стало его причиной.

Добавьте GPU сведения

Руководство NVIDIA Xid описывает сбор и разбор GPU ошибок. Xid и AER — разные свидетельства, которые могут относиться к одному эпизоду, но не образуют универсальную таблицу взаимно однозначного соответствия. Сохраните driver version и идентичность GPU. Если Xid отсутствует, это не опровергает наблюдение AER; если он присутствует, один номер еще не доказывает неисправность конкретной детали. Сопоставляйте дополнительные данные и поддерживаемые процедуры диагностики выбранной платформы вместо случайного сброса работающей карты ради проверки гипотезы.

Оформите доказательства до вмешательства

Итоговый пакет включает полные логи, topology, versions, workload phase и наблюдения после события. Отдельно укажите, что было изменено при обслуживании и когда. Не превращайте статью в инструкцию отключать AER reporting или выполнять reset в production: такие действия могут уничтожить нужную картину и затронуть соседние устройства. Для повторения используйте согласованную тестовую среду. Полезный вывод различает факт ошибки интерфейса, путь отчетности и установленную причину. Если последняя пока неизвестна, так и сформулируйте, не подменяя отсутствие локализации уверенностью в неисправности GPU только из-за близости сообщений в журнале или временного прекращения ответа LLM endpoint во время той же наблюдаемой серии.

Связанные материалы

PCIe и GPU-хостинг: когда соединение ограничивает модель; Журнал сетевого перерыва GPU-узла: какие времена и события записать.