[Question] Where to investigate DMAR interrupt-remap warning observed near four-B70 initialization?

Abierto
#1,054 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
cpp, linux, ubuntu

Línea de trabajo

The issue does not identify a compute-runtime file, test, or confirmed runtime version, and asks who owns the warning. Start by checking the kernel’s DMAR/IOMMU logs and PCI device inventory alongside the compute-runtime version and a minimal reproducer; the issue provides no specific commands or files to begin with. Done means identifying the appropriate owning team and the non-invasive evidence needed to triage the source.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Question Category

Compatibility

Question

On an Ubuntu 26.04.1 four-Intel-Arc-Pro-B70 system, we observed the Linux kernel report an interrupt-remapping source-ID verification failure around Level Zero/oneCCL initialization. Is this appropriate for compute-runtime triage, or should we report it to a kernel IOMMU, board/firmware or other team? Which specific non-invasive logs would help identify the source?

DMAR: DRHD: handling fault status reg 2
DMAR: [INTR-REMAP] Request device [00:1b.4] fault index 0x2 [fault reason 0x26] Blocked an interrupt request due to source-id verification failure

We are not asserting a compute-runtime or GPU-driver defect. The same pair appeared at boot and again outside the test container's lifetime. The printed 00:1b.4 did not correspond to an enumerated 0000:00:1b.4 in our inspection. Another PCI address, 0000:24:1b.4, is distinct and has not been identified as the requester.

Additional Notes

  • ASUS Pro WS W890E-SAGE SE, BIOS 0507; 4 x Arc Pro B70; Ubuntu 26.04.1, kernel 7.0.0-43-generic, kernel driver xe.
  • A synthetic, model-free four-process Torch XPU / oneCCL all-reduce test was stopped by our monitor after the pair appeared during startup. The retained output did not show a completed collective; this is not evidence the collective failed. The same pair was observed again around 55 seconds after the container was removed.
  • An earlier Ornith model service returned responses after the same warning. That does not prove the warning is harmless or that unrelated devices are unaffected.
  • Torch 2.11.0+xpu, Triton XPU 3.7.0; a locally adapted vLLM/oneCCL stack and rebuilt extension were present, but the selected oneCCL implementation has not been verified. A minimal portable reproducer and current compute-runtime driver version have not yet been established.
  • We searched this repository for DMAR and INTR-REMAP; we did not find a matching report. We have not verified that the installed GPU runtime is the latest version.

We would appreciate guidance on the correct owner and useful evidence before proposing any workaround or attributing the fault to a particular component.

Related environment discussion: https://github.com/steveseguin/b70-optimization-lab/issues/84

Lenguaje dominante
C++
Estrellas
1.5k
Forks
306
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de intel/compute-runtime

Todos los issues de intel/compute-runtime

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.