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
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
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
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de intel/compute-runtime
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
intel/compute-runtime#1040 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
intel/compute-runtime#943 ·
-
[Question] Where to investigate DMAR interrupt-remap warning observed near four-B70 initialization?Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
intel/compute-runtime#1054 ·
-
Type: Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
intel/compute-runtime#1053 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
intel/compute-runtime#1051 · 1 comentario ·
Todos los issues de intel/compute-runtime
Issues similares
-
runtime: lf_f128_mod is documented as fmodq (truncating) but implements floor-based modulo; unusedAbiertointernal correctness low priority rt_lib
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 87/100
-
PriorityNotificationQueue::wakeUpAll() loses the wake-up for a thread that is not waiting yetPosiblemente ocupada @matejk la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
pocoproject/poco#5674 ·
Los mantenedores suelen responder en 2 días
-
bug docs GUI
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
sonic-pi-net/sonic-pi#3609 ·
-
Unreachable code warningAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
SanderMertens/flecs#2395 ·
Los mantenedores suelen responder en 1 día