GPU Compute Software
Ask questions about Intel® Graphics Compute software technologies, such as OpenCL* GPU driver and oneAPI Level Zero
Announcements
Important Update: Community Platform Migration​. Learn more​>
519 Discussions

Xe driver: GuC scheduling timeout / engine reset (bcs) during multi-GPU workload on 2x Arc Pro B50

AndreaC24
Beginner
214 Views

Hi everyone,

I'm running a dual Intel Arc Pro B50 setup for local LLM inference (OpenVINO GenAI, HETERO multi-device pipeline parallelism) on Ubuntu 24.04, and I'm running into a reproducible crash that seems to originate at the Xe driver / GuC level rather than in userspace.

Setup:

  • 2x Intel Arc Pro B50 (16GB each), PCI IDs 0000:0b:00.0 and 0000:0f:00.0
  • Both cards confirmed running at PCIe 4.0 x8 (motherboard: ASUS ROG Strix X570-E Gaming WiFi II, CPU lane bifurcation x8/x8, verified via lspci)
  • CPU: AMD Ryzen 5 3600X
  • Ubuntu 24.04, kernel 7.0.0-30-generic (Xe driver)
  • OpenVINO 2026.4.0.dev20260825 / OpenVINO GenAI 2026.4.0.0.dev20260825

What I'm doing: Loading a large language model (INT4 quantized, ~27B parameters, too large for a single 16GB card) split across both GPUs using OpenVINO's HETERO pipeline-parallel mode (HETERO:GPU.0,GPU.1 with MODEL_DISTRIBUTION_POLICY="PIPELINE_PARALLEL"). The model loads successfully on both cards, but the process crashes as soon as generation starts — specifically when data needs to move between the two GPUs.

What shows up in dmesg, consistently, even right after a clean reboot (so it's not leftover state from a previous run):

 
python[5276]: segfault at 7c33dad22e50 ip 00007c39cbb88d6b sp 00007c346d4e9588 error 4 in libc.so.6[188d6b,7c39cba28000+188000] likely on CPU 6 (core 0, socket 0)

xe 0000:0f:00.0: [drm] Tile0: GT0: Engine reset: engine_class=bcs, logical_mask: 0x1, guc_id=9, state=0x289
xe 0000:0f:00.0: [drm] Tile0: GT0:
   ASID: 5
   Faulted Address: 0x0000d556aa740000
   FaultType: 0
   AccessType: 0
   FaultLevel: 4
   EngineClass: 3 bcs
   EngineInstance: 0
xe 0000:0f:00.0: [drm] Tile0: GT0: Fault response: Unsuccessful -ENOENT

xe 0000:0b:00.0: [drm] Tile0: GT0: Engine reset: engine_class=bcs, logical_mask: 0x1, guc_id=9, state=0x289
xe 0000:0b:00.0: [drm] Tile0: GT0:
   ASID: 9
   Faulted Address: 0x0000c001ffd40000
   FaultType: 0
   AccessType: 0
   FaultLevel: 4
   EngineClass: 3 bcs
   EngineInstance: 0
xe 0000:0b:00.0: [drm] Tile0: GT0: Fault response: Unsuccessful -ENOENT

xe 0000:0f:00.0: [drm] *ERROR* Tile0: GT0: Timed out wait for G2H, fence 2260, action 0509, done no
xe 0000:0f:00.0: [drm] *ERROR* Tile0: GT0: failed to enable GuC scheduling policies: -ETIME

Both GPUs fault symmetrically, both on the bcs (blitter/copy) engine, both with -ENOENT (unmapped/invalid address). This engine is specifically the one responsible for moving data between devices, which lines up with this only happening in the multi-GPU pipeline-parallel path — single-GPU inference on the same hardware, same model, works completely fine.

A few things I've already ruled out:

  • Not stale driver/VRAM state — reproduces on the very first load/generate attempt after a full reboot.
  • Not a PCIe bandwidth/bifurcation issue — both cards confirmed at PCIe 4.0 x8 via lspci -vv.
  • Not deterministic in its userspace symptom — I've seen this same underlying issue surface differently across runs on the OpenVINO side (explicit CL_INVALID_EVENT exception, silent segfault inside libopenvino.so, or this segfault+GuC timeout), which points to a race condition rather than a fixed logic bug.

I've also filed a report on the OpenVINO GitHub repo focused on the userspace/plugin side of this (referencing the existing related issue openvinotoolkit/openvino#37006, which reports similar symptoms on 2x Arc A770 under Windows), but the GuC timeout and engine reset specifically looked like it belonged here on the driver side too.

Has anyone else seen bcs engine resets / GuC scheduling timeouts on multi-GPU Xe setups, particularly under workloads that require cross-device data transfer? Any known issues or workarounds, or is this still an open area for the Arc Pro B-series multi-GPU path?

Happy to provide more logs, dmesg output, or test candidate driver builds if that's useful.

Thanks!

0 Kudos
0 Replies
Reply