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

Đang mở
  • Có gì không ổn?
#1,052 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
backend, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C++
Star
1.5k
Fork
306
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của intel/compute-runtime

Tất cả issue của intel/compute-runtime

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.