Description

On Intel Arc B580 (Battlemage, xe kernel driver), Forza Horizon 5 and Forza
Horizon 6 either crash with FHC00 "Video Card Crash" or fully freeze the
system shortly after launch (input dies, GPU hangs, hard reboot required).

Root cause appears to be that vkd3d-proton issues a DRM_IOCTL_XE_VM_BIND
that the kernel rejects with -EOPNOTSUPP, then retries the same bind in a
tight loop instead of failing the operation. The kernel logs a WARNING at
drivers/gpu/drm/xe/xe_vm.c:1169 on every retry, and eventually the system
locks up.

Other DX12 games on the same hardware/setup via vkd3d-proton work fine.
Forza titles are reported working under vkd3d-proton on AMD/Nvidia per
ProtonDB — only Intel Arc / xe users report this failure mode (cross-
referenced across FH5 and FH6 reports).

System

• GPU: Intel Arc B580 [8086:e20b] (Battlemage G21)
• Kernel driver: xe
• Mesa / Vulkan driver: Mesa 26.1.0 (ANV, DRIVER_ID_INTEL_OPEN_SOURCE_MESA), Vulkan 1.4.348
• Kernel: 6.18.0-cachyos (NixOS build)
• Distro: NixOS unstable, Hyprland/Wayland
• Proton tested: GE-Proton 10-34, Proton Experimental
• CPU: AMD Ryzen 7 9700X, MSI B850 GAMING PLUS WIFI
• Single GPU (no iGPU active), ReBAR enabled (BAR2 = 16G prefetchable)

Affected games

• Forza Horizon 6
• Forza Horizon 5 — same symptom

Other vkd3d-proton DX12 titles on this setup are unaffected.

Symptom

1. Launch Forza via Steam with GE-Proton 10-34
2. Game reaches menu then loading screen
3. Either crashes with FHC00 (vkd3d-proton's DX12 device-removed surface),
   or freezes the entire system (full GPU hang requiring hard reboot)
4. dmesg shows the kernel WARN below repeating indefinitely until the
   vkd3d_queue thread is killed or the system hangs

Kernel splat (one iteration; repeats)

WARNING: CPU: 2 PID: 51476 at drivers/gpu/drm/xe/xe_vm.c:1169 xe_vm_bind_ioctl+0x179c/0x1e00 [xe]
CPU: 2 UID: 1000 PID: 51476 Comm: vkd3d_queue Tainted: G     UD W  OE       6.18.0-cachyos #1-NixOS PREEMPT(full)
RIP: 0010:xe_vm_bind_ioctl+0x179c/0x1e00 [xe]
RAX: ffff89f36542c380 RBX: ffff89f21d0a13f0 RCX: 0000effd801fffff
RDX: 0000000000000000 RSI: ffff89f439d8b300 RDI: ffff89f5fbd604e0
RBP: ffffd06ce4b4fc30 R08: 0000000000000000 R09: 0000effd7ff90000
R10: ffff89f20d723000 R11: ffff89f200042d00 R12: ffff89f221cc7b80
R13: ffff89f5fbd60160 R14: ffff89f5fbd604e0 R15: 00000000ffffffef
CR2: 0000000061785000

Call Trace:
 drm_ioctl_kernel+0xae/0x100
 drm_ioctl+0x29b/0x510
 xe_drm_ioctl+0x4f/0x80 [xe]
 __x64_sys_ioctl+0x97/0xe0
 do_syscall_64+0x81/0x7f0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

ioctl: 0x40886445 (DRM_IOCTL_XE_VM_BIND)
return value: R15 = 0xffffffef = -EOPNOTSUPP (-17)
userspace address being bound: CR2 = 0x61785000 (constant across iterations)

What I think is happening on the vkd3d side

The xe driver returns -EOPNOTSUPP from a particular VM_BIND path.
Whatever bind operation vkd3d-proton is requesting either:

• isn't supported by xe at all yet, or
• is being constructed in a way xe doesn't accept for Battlemage

Either way, vkd3d-proton appears to retry the same failing bind (same target
address CR2: 0x61785000 every iteration) rather than failing the operation
or falling back. The retry loop is what eventually locks the system.

A companion kernel bug is filed against xe to investigate the EOPNOTSUPP
itself: .

Asks

1. Defensive handling for VM_BIND returning -EOPNOTSUPP — even if/when
   xe is fixed, gracefully failing or falling back here would prevent system
   freezes from any future driver edge case across all kernel drivers, not
   just xe.

2. Is there a VKD3D_CONFIG flag that avoids whatever specific bind
   operation pattern is being rejected by xe? Worth knowing if there's a
   known-good codepath for Battlemage to recommend in the meantime.

3. Forza titles are known to use unusual DX12 placed-resource / tiled-resource
   memory patterns. If vkd3d-proton has any per-game quirks or per-driver-id
   workarounds, Forza on xe may need one until xe matures.

Workarounds tried (all unsuccessful)

• VKD3D_CONFIG=virtual_heaps,no_upload_hvv,single_queue
• GE-Proton 10-34 → Proton Experimental
• In-game graphics quality reductions
• Not VRAM-bound (no eviction/OOM in dmesg, only the WARN above)