Linux Kernel 6.18 support?

[plumlis]

I have been running Ollama on an ARL-H U258H laptop with 64GB RAM, Fedora 43, using Intel IPEX.
I was using the Intel officially recommended Docker image for inference:

https://hub.docker.com/r/intelanalytics/ipex-llm-inference-cpp-xpu

This setup had been working reliably before.

A few days ago I upgraded my system kernel to Linux 6.18, and since then Ollama models can no longer be loaded when using IPEX. The main error I see is:

“Native API failed. Native API returns: 39 (UR_RESULT_ERROR_OUT_OF_DEVICE_MEMORY)”

get_memory_info: [warning] ext_intel_free_memory is not supported (export/set ZES_ENABLE_SYSMAN=1 to support), use total memory as free memorytime=2025-12-14T00:04:07.339+08:00 level=INFO source=server.go:652 msg="waiting for server to become available" status="llm server loading model"

[GIN] 2025/12/14 - 00:04:06 | 200 |      23.915µs |       127.0.0.1 | HEAD     "/"
[GIN] 2025/12/14 - 00:04:06 | 200 |  125.603561ms |       127.0.0.1 | POST     "/api/show"
Native API failed. Native API returns: 39 (UR_RESULT_ERROR_OUT_OF_DEVICE_MEMORY)
Exception caught at file:/home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/ggml-sycl.cpp, line:405, func:operator()
SYCL error: CHECK_TRY_ERROR(ctx->stream->memset( (char *)tensor->data + original_size, 0, padded_size - original_size).wait()): Exception caught in this line of code.
  in function ggml_backend_sycl_buffer_init_tensor at /home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/ggml-sycl.cpp:405
/home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/../ggml-sycl/common.hpp:115: SYCL error

From the behavior, it looks like the GPU is detected and accessible, but device memory allocation always fails.

At first I suspected the Docker image might be too old, so I tried several alternatives:

Building and running Ollama manually against the local runtime

Running via ramalama (llama.cpp based container with Intel GPU support)

None of these worked on kernel 6.18.
For ramalama, the error message is:

:: initializing oneAPI environment ...
   entrypoint.sh: BASH_VERSION = 5.3.0(1)-release
   args: Using "$@" for setvars.sh arguments: llama-server -m /models/model.gguf --host 0.0.0.0 --port 8080
:: compiler -- latest
:: mkl -- latest
:: tbb -- latest
:: umf -- latest
:: oneAPI environment initialized ::
 
Abort was called at 70 line in file:
/builddir/build/BUILD/intel-compute-runtime-25.31.34666.3-build/compute-runtime-25.31.34666.3/shared/source/helpers/bindless_heaps_helper.cpp

I have also updated to the latest intel-compute-runtime available in the Fedora repositories, but the issue persists.

Importantly, if I boot back into kernel 6.17, everything works correctly again. Both the Intel IPEX Docker image and ramalama run without issues on 6.17.

I checked the Linux 6.18 changelog and did not notice any obvious changes related to GPU memory management or Intel Xe that would clearly explain this behavior.

I have already opened an issue on the IPEX side as well,：intel/ipex-llm#13334

but I wanted to ask here:
Is kernel 6.18 currently unsupported or unvalidated for IPEX / compute-runtime based workloads?
Or is there a known incompatibility between Linux 6.18 and the current Intel GPU userspace stack?

I also noticed discussions mentioning that Intel GPU support has been merged upstream into Ollama, but from what I can see this appears to be limited to experimental Vulkan support, not the IPEX / Level Zero path.

Any clarification on the expected kernel support status would be greatly appreciated.

[HoppeMateusz]

@plumlis - can you run with environment variables:

NEOReadDebugKeys=1 PrintDebugSettings=1 UseExternalAllocatorForSshAndDsh=0

to eliminate bindless heaps helper issue?

[plumlis]

Hi,thank you very much for your reply

Because my previous attempt to build PyTorch from source and messed up my system, I restored my system from a btrfs snapshot. So I tested again using xpu docker images and ramalama’s Intel GPU containers first, with the environment variables and parameters you suggested.

Here are logs：

ipex-llm-inference-cpp-xpu.log

ranllama.log

What I find confusing is that even on kernel 6.17, in cases where the model does successfully load and start, the following warning still appears consistently:

get_memory_info: [warning] ext_intel_free_memory is not supported
(export/set ZES_ENABLE_SYSMAN=1 to support), use total memory as free memory

I don’t understand why the newer kernel fails while the older one works. It feels quite strange.

[HoppeMateusz]

i am now seeing there is no abort due to UNRECOVERABLE in bindless heaps helper, but out of memroy error is there:

[GIN] 2025/12/15 - 22:08:04 | 200 |    80.23361ms |       127.0.0.1 | POST     "/api/show"
Non-default value of debug variable: PrintDebugSettings = 1
Non-default value of debug variable: UseExternalAllocatorForSshAndDsh = 0
Non-default value of debug variable: PrintDebugSettings = 1
Non-default value of debug variable: UseExternalAllocatorForSshAndDsh = 0
using override patterns: []
Non-default value of debug variable: PrintDebugSettings = 1
Non-default value of debug variable: UseExternalAllocatorForSshAndDsh = 0
Non-default value of debug variable: PrintDebugSettings = 1
Non-default value of debug variable: UseExternalAllocatorForSshAndDsh = 0
Native API failed. Native API returns: 39 (UR_RESULT_ERROR_OUT_OF_DEVICE_MEMORY)
Exception caught at file:/home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/ggml-sycl.cpp, line:405, func:operator()
SYCL error: CHECK_TRY_ERROR(ctx->stream->memset( (char *)tensor->data + original_size, 0, padded_size - original_size).wait()): Exception caught in this line of code.
  in function ggml_backend_sycl_buffer_init_tensor at /home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/ggml-sycl.cpp:405
/home/runner/_work/llm.cpp/llm.cpp/ollama-llama-cpp/ggml/src/ggml-sycl/../ggml-sycl/common.hpp:115: SYCL error
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib[0x117b058]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib(ggml_abort+0x136)[0x117b3c6]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/libggml-sycl.so(+0x86a88)[0x7f7644686a88]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/libggml-sycl.so(+0x89fd1)[0x7f7644689fd1]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib[0x1168fe8]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib(ggml_backend_alloc_ctx_tensors_from_buft+0xff)[0x116a1cf]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/libllama.so(_ZN11llama_model12load_tensorsER18llama_model_loader+0x1ea65)[0x7f7643eea0c5]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/libllama.so(+0x64164)[0x7f7643e64164]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/libllama.so(llama_model_load_from_file+0xec)[0x7f7643e6377c]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib(_cgo_89fafab9cb6c_Cfunc_llama_model_load_from_file+0x4b)[0x1159acb]
/usr/local/lib/python3.11/dist-packages/bigdl/cpp/libs/ollama/ollama-lib[0x4a1f64]
SIGABRT: abort
PC=0x7f764306d9fc m=4 sigcode=18446744073709551610
signal arrived during cgo execution
goroutine 

looks that system is heavily under memory pressure - i see there are multiple processes running that are using level zero driver.

i dont think this is something compute runtime can resolve.

[plumlis]

Well, I’m not entirely sure what’s going on either, but for now the same Docker container (from Intel’s official documentation) works fine on kernel 6.17. It may have some memory leaks after running for a long time, but it starts without any problem.

On kernel 6.18, it fails at startup, and the error message is exactly what you mentioned: “out of memory.” Nothing else in the environment was changed, only the kernel version. A container that previously worked simply cannot start anymore.

Since I need to run large models for some RAG-related work, I’ve temporarily rolled back to the older kernel. Honestly, I’m not sure where this bug or issue should be reported. For now, I’ll just stay on 6.17 and continue my work.

Anyway, Thanks for your help.

[plumlis]

It seems I finally find something related:
pytorch/pytorch#157989

[plumlis]

I’ve gone through a series of tests, including installing a newer kernel (6.19 RC1), building my own Docker image, and using the latest Intel oneAPI runtimes and related components. So far, the situation remains the same: I’m unable to retrieve the Intel Arc GPU memory information.

My personal guess is that this is very likely related to some changes in the Intel Xe driver introduced around the 6.18 kernel series. After rolling back to kernel 6.17.12, even though there are many warnings and errors when running larger models, it does at least work.

At this point, I’m not sure how this issue should be resolved, or even where it should be reported. I also don’t know whether this is a bug, or whether there were API changes on the Xe side that now require matching updates in the user-space drivers. Due to time constraints, I’ve decided to stick with kernel 6.17.12 for now.

[kgibala]

Hi @plumlis,

Thank you for your detailed report. I understand that you are encountering the following warning, even when the model loads and starts successfully on kernel 6.17.

What I find confusing is that even on kernel 6.17, in cases where the model does successfully load and start, the following warning still appears consistently:

get_memory_info: [warning] ext_intel_free_memory is not supported
(export/set ZES_ENABLE_SYSMAN=1 to support), use total memory as free memory

Based on your description, you are using release 25.31.34666.3 (intel-compute-runtime-25.31.34666.3). This functionality has been updated in the latest release, 25.48.36300.8. I recommend upgrading to this version, as it should resolve the warning you are seeing.

If the problem is still present with the latest software stack, please provide additional information that would assist us in further investigating of the issue:

• Please collect memory pressure statistics using the XPUManager tool. Instructions can be found in the:
  https://github.com/intel/xpumanager/blob/master/doc/smi_user_guide.md#dump-the-device-statistics-in-csv-format
  Example:

xpu-smi dump -d 0 -m 0,1,2,5,17,18
...
12:37:36.229,    0,  N/A, 105.27, 1550, 62.56,  N/A, 30743.83
...

• Provide the complete setup information as reported by XPUManager, following the example in the:
  https://github.com/intel/xpumanager/blob/master/doc/smi_user_guide.md

Show the detailed info of one device. The device info includes the model, frequency, driver/firmware info, PCI info, memory info and tile/execution unit info.

xpu-smi discovery -d 0000:4d:00.0
+-----------+--------------------------------------------------------------------------------------+
| Device ID | Device Information                                                                   |
+-----------+--------------------------------------------------------------------------------------+
| 0         | Device Type: GPU                                                                     |
|           | Device Name: Intel(R) Graphics [0x020a]                                              |
...

• Sharing relevant API calls and kernel logs (dmesg):

UR_L0_DEBUG=-1 SYCL_UR_TRACE=-1 ZE_DEBUG=-1 <app>

• The version of the oneAPI stack you are using.
• If possible, please include the steps to reproduce the issue. This will help us attempt to recreate the problem on our side.

Thank you for your cooperation.