[Arrow Lake] System Hangs & >4GB Allocation Failures on OEM Device with Fixed 256MB BAR

[psilofski]

System Info:

CPU: Intel Core Ultra 7 (Arrow Lake 255H / ThinkBook 16 G8)
GPU: Intel Arc iGPU (Xe-LPG / 140T)
OS: Ubuntu 24.04 (Kernel 6.17). (Issue also verified reproducible on Windows 11 with latest drivers)
Driver: Intel Compute Runtime (Level Zero / NEO)

Issue Description:
I am encountering two distinct, reproducible failure modes on this Arrow Lake platform under compute workloads (PyTorch/OpenVINO):

1. Allocation Failure (OOM): The runtime fails to allocate single contiguous memory blocks larger than ~4GB, despite the system having 60GB+ of free RAM. (Allocating the same total amount in smaller chunks succeeds).
2. System Instability (Kernel Panic): During heavy compute tasks involving high-bandwidth access (e.g., VAE Decode, Large Context LLM), the system suffers hard freezes/kernel panics, likely due to GTT thrashing.

Cross-Validation:
This behavior (Hard Freezes on heavy load, Allocation limits) is observed on both Windows 11 and Linux, strongly suggesting a platform-level firmware constraint rather than an OS-specific driver bug.

Root Cause Investigation:
lspci indicates that the device supports Physical Resizable BAR. However, the OEM firmware (Lenovo) locks the CPU-visible aperture to a legacy 256 MB, with no exposed option to enable or resize it.

Context:
My understanding is that Intel Arc iGPUs (Xe-LPG) share the same Arc driver stack, virtual memory model, and BAR-style aperture management as discrete Arc GPUs. Discrete Arc GPUs are documented as requiring ReBAR for optimal performance and stability.

Questions:

1. Architecture: Does the Arrow Lake Arc iGPU share the architectural requirement for Large/Resizable BAR to ensure stability under heavy compute workloads?
2. Compliance: Is the Compute Runtime expected to handle >4GB contiguous allocations and heavy thrashing gracefully within a 256 MB aperture, or is this considered an unsupported or out-of-spec firmware configuration for this platform??
3. Triage: Should these crashes be filed as a memory-management bug in the driver, or is this a platform limitation that must be resolved by the OEM firmware?

Goal:
I am trying to determine whether to open a bug report against the driver's memory manager or if I have grounds to escalate this as a firmware defect to the OEM.

Any clarification on the architectural expectations for BAR sizing on Arrow Lake would be greatly appreciated.

[GheorgheMorari]

Hello, I just noticed that ReBAR is also disabled on an Asus (Core Ultra 9 285H) device running Windows 11.
I have the latest driver installed 32.0.101.8509, and GPU-Z reports the following reasons why Resizeable BAR is disabled:

PCI-Express Resizable BAR
Resizable BAR Disabled

Resizable BAR Requirements
GPU Hardware Support Yes
Above 4G Decode enabled in BIOS Yes
Resizable BAR enabled in BIOS No
CSM disabled Yes
Boot from GPT Yes
64-Bit Operating System Yes
Windows running in UEFI Mode Yes
Graphics Driver Support No

PCI-Express BAR Sizes
BAR0 256 MB

I did some research, and It looks like ReBAR is not applicable to Intel's IGPUs as those don't have dedicated VRAM.
I may be wrong and this might be a valid issue.

[kgibala]

Hi @psilofski,

Thank you for your contribution and for reporting this problem.

I created a simple reproducer based on the Level Zero API.

./reproducer

Device: Intel(R) Arc(TM) Graphics

Memory Properties:
  Memory[0]:
    Total Size: 13.7823 GB
    Max Clock Rate: 0 MHz

Max Allocation Size:
  maxMemAllocSize: 3.99999 GB (4294959104 bytes)

=== Allocation Tests ===
Testing single contiguous allocations...

Attempting to allocate 1 GB... SUCCESS (ptr=0xffffd556aaa00000)
Attempting to allocate 2 GB... SUCCESS (ptr=0xffffd556aaa00000)
Attempting to allocate 4 GB... FAILED (error code: 2013265929)
Attempting to allocate 5 GB... FAILED (error code: 2013265929)
Attempting to allocate 8 GB... FAILED (error code: 2013265929)

=== Chunked Allocation Test ===
Attempting to allocate 8 GB in 1 GB chunks...

  Chunk 1/8 SUCCESS
  Chunk 2/8 SUCCESS
  Chunk 3/8 SUCCESS
  Chunk 4/8 SUCCESS
  Chunk 5/8 SUCCESS
  Chunk 6/8 SUCCESS
  Chunk 7/8 SUCCESS
  Chunk 8/8 SUCCESS

The error code translates to:

Attempting to allocate 4 GB... 
>>>> [9033301069566] zeMemAllocDevice: hContext = 0x616888b39208 device_desc = 0x7ffdb9af4200 {ZE_STRUCTURE_TYPE_DEVICE_MEM_ALLOC_DESC(0x15) 0 0 0} size = 0x100000000 alignment = 0x0 hDevice = 0x616888b21f08 pptr = 0x7ffdb9af41e0 (ptr = 0x0)
<<<< [9033301072569] zeMemAllocDevice [139 ns] -> ZE_RESULT_ERROR_UNSUPPORTED_SIZE(0x2013265929)

As we can see, the maxMemAllocSize is 4GB for this machine, so the error code is expected.

---

Allocation limit sizes can be updated using the relaxed allocation limits extension:

• ZE_RELAXED_ALLOCATION_LIMITS_EXP_FLAG_MAX_SIZE

./reproducer

Device: Intel(R) Arc(TM) Graphics

Memory Properties:
  Memory[0]:
    Total Size: 13.7823 GB
    Max Clock Rate: 0 MHz

Max Allocation Size:
  maxMemAllocSize: 3.99999 GB (4294959104 bytes)

=== Allocation Tests ===
Testing single contiguous allocations...

Attempting to allocate 1 GB... SUCCESS (ptr=0xffffd556aaa00000)
Attempting to allocate 2 GB... SUCCESS (ptr=0xffffd556aaa00000)
Attempting to allocate 4 GB... FAILED (error code: 2013265929)
Attempting to allocate 5 GB... FAILED (error code: 2013265929)
Attempting to allocate 8 GB... FAILED (error code: 2013265929)

=== Relaxed Allocation Limits Test (ZE_RELAXED_ALLOCATION_LIMITS_EXP) ===
Using ZE_RELAXED_ALLOCATION_LIMITS_EXP_FLAG_MAX_SIZE to bypass maxMemAllocSize cap...

Attempting to allocate 4 GB with relaxed limits... SUCCESS (ptr=0xffffd556aaa00000)
Attempting to allocate 5 GB with relaxed limits... SUCCESS (ptr=0xffffd556aaa00000)

=== Chunked Allocation Test ===
Attempting to allocate 8 GB in 1 GB chunks...

  Chunk 1/8 SUCCESS
  Chunk 2/8 SUCCESS
  Chunk 3/8 SUCCESS
  Chunk 4/8 SUCCESS
  Chunk 5/8 SUCCESS
  Chunk 6/8 SUCCESS
  Chunk 7/8 SUCCESS
  Chunk 8/8 SUCCESS

Note: In this example, no extra BAR sizes were applied.

---

Please ensure that you are respecting the maxMemAllocSize value, or use the recommended relaxed allocation properties mentioned above to exceed it.

I hope this message provides a solution to your problem.

Thanks again for the contribution.

[psilofski]

Thank you for the detailed technical analysis and for providing the reproducer.

I appreciate the confirmation that the ~4 GB maxMemAllocSize is derived from the platform configuration rather than from total available system memory.

Regarding the suggested workaround:
The ZE_RELAXED_ALLOCATION_LIMITS_EXP_FLAG_MAX_SIZE flag must be passed programmatically via the Level Zero API struct. Unfortunately, this flag is not exposed through environment variables or runtime knobs in common end-user stacks (PyTorch, IPEX, OpenVINO). This makes it impractical as a mitigation for validating stability without modifying the source code and rebuilding the software stack.

More importantly, this allocation limit is secondary to a critical stability issue.

Even when workloads fully respect maxMemAllocSize (e.g., tiled processing, reduced batch sizes, no single allocations >4 GB), the system still exhibits hard freezes / kernel panics under heavy compute workloads.

Observed behavior:

1. Workloads whose individual allocations respect the 4 GB limit, but whose total working set significantly exceeds the fixed 256 MB BAR aperture, trigger extreme GTT thrashing.
2. Under non-linear memory access patterns (e.g., scatter/gather operations, high-resolution VAE decode, complex attention mechanisms), the System Agent appears to deadlock, resulting in kernel panics such as: "Timeout: not all CPUs entered broadcast exception handler".

This suggests that the fixed 256 MB CPU-visible aperture is structurally insufficient for heavy compute workloads on this architecture, leading to instability even when software strictly adheres to documented allocation limits.

Clarification Request:
Can Intel confirm whether Large / Resizable BAR apertures are an architectural expectation or recommendation for platform stability on Arrow Lake (Xe-LPG) Arc iGPU compute workloads?

If so, this would indicate that platforms shipping with a permanently fixed 256 MB aperture represent an unsupported or unvalidated configuration for such workloads, and that resolution must occur at the OEM firmware level.

This clarification is vital to determine whether further bug reports should target the compute runtime memory manager, or whether the correct path is to escalate the issue to the platform vendor (OEM).

Thank you for the clarification.

UPDATE:
I’ve just confirmed that when using the Unified Runtime path, setting
UR_L0_ENABLE_RELAXED_ALLOCATION_LIMITS=1 does allow allocations exceeding the 4 GB maxMemAllocSize without recompiling the stack.

However, this does not change the core issue described earlier