Arc Pro B70 (BMG G31): CCS page fault (Engine memory CAT error, two VAs 4 MiB apart) on the first replay of a recorded SYCL graph

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp
Área
backend, devtools

Línea de trabajo

Start by reviewing the SYCL command graph recording and replay path in the Intel Compute Runtime, then compare it with the eager queue submission described here. The report includes no source file, test, or specific reproduction command; use the supplied graph workload and driver logs to investigate the two faulting virtual addresses. Done means identifying the replay failure and a reproducible diagnostic or fix.

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

Descripción

Pre-submission Checklist
  • I am using the latest GPU driver version: compute-runtime 26.40.40196.8, IGC 2.42.6 (ppa:kobuk-team/intel-graphics)
  • I have searched for similar issues: closest are #1010 (unbound kernel private surface, Engine memory CAT error on Arc Pro B70) and #948 (B70 ccs/bcs reset with Fault response: Unsuccessful -ENOENT); the trigger here is SYCL graph (command-buffer) replay
GPU Hardware

Intel Arc Pro B70 (Battlemage G31, PCI 8086:e223, ASRock subsystem 1849:6025), passed through with vfio to a KVM guest (one GPU in the guest).

DRI Devices Information
crw-rw---- 1 root video  226,   0 card0
crw-rw---- 1 root render 226, 128 renderD128
pci-0000:01:00.0-card -> ../card0
pci-0000:01:00.0-render -> ../renderD128
GPU Detailed Information (lspci output)
01:00.0 VGA compatible controller [0300]: Intel Corporation Battlemage G31 [Intel Graphics] [8086:e223]
	Subsystem: ASRock Incorporation Device [1849:6025]
	Kernel driver in use: xe
Software
  • Guest OS: Ubuntu 26.04.1 LTS, kernel 7.0.0-43-generic (in-kernel xe), GuC 70.72.1
  • compute-runtime (NEO) 26.40.40196.8, IGC 2.42.6, Level Zero loader 1.35.0
  • oneAPI DPC++ 2025.3.3, Unified Runtime 0.12.0
Description

An LLM decode step (a ggml SYCL backend, 1,369 nodes) is recorded once with sycl_ext_oneapi_graph (68 segments) and replayed. The first
replay faults on the compute engine before the step completes; the same work submitted eagerly to the queue completes correctly and
repeatably on the same machine.

Kernel log at the fault (one of several identical windows):

xe 0000:01:00.0: [drm] Tile0: GT0: ASID: 11 Faulted Address: 0x0000d4dde03a0000 FaultType: 0 AccessType: 1 FaultLevel: 3 EngineClass: 5 ccs EngineInstance: 0
xe 0000:01:00.0: [drm] Tile0: GT0: Fault response: Unsuccessful -ENOENT
xe 0000:01:00.0: [drm] Tile0: GT0: Engine memory CAT error [18]: class=ccs, logical_mask: 0x1, guc_id=2
xe 0000:01:00.0: [drm] Tile0: GT0: Timedout job: seqno=4294967211, lrc_seqno=4294967211, guc_id=2, flags=0x20 in luce_server [4680]
xe 0000:01:00.0: [drm] Xe device coredump has been created

followed by one CCS engine reset (state 0x249); the device recovers and enumerates.

What we have measured across eleven such windows:

  • Each window faults on two GPU virtual addresses exactly 4 MiB apart.
  • With allocation tracing on, neither address lies in any of the 2,457 allocations the process made through the runtime, nor in a semaphore.
  • All 825 recorded kernels' pointer arguments (2,630 tensor views) and integer inputs lie within live allocations at recording time.
  • The fault is the same with three GEMM paths (oneDNN primitives, persistent oneDNN primitives with dedicated scratch, and the native
    BLAS path) and with attention workspaces kept persistent for the graph's lifetime.
  • It is the same with immediate command lists (default) and with regular command lists (SYCL_UR_USE_LEVEL_ZERO_V2=0,
    SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=0; the UR log confirms regular-list execution, 271 executions after recording).
  • Devcoredumps (about 400-440 KB) are captured; their VM snapshot reports error -19, so they carry no BO payload.

Because the faulting addresses sit outside every user allocation, a driver-owned surface (for example a kernel private / scratch surface,
as in #1010) left unbound at replay time would fit the pattern.

Ask

Is this a known command-buffer replay issue on Battlemage / xe, and which debug settings (Level Zero / NEO debug keys, xe tracing) would you
like captured? We can run any diagnostic build or environment on this machine and share the logs and coredumps.

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.