[GSD-13316] Repeated SIGSEGV in `DrmCommandStreamReceiver<Gen12LpFamily>::makeNonResident` under sustained multi-context OpenCL load (Gen12LP / N97, 25.18.33578.15)

[matt73200]

Pre-submission checklist

• I searched existing issues — no duplicate found.
• I am NOT on the latest driver version. See "Driver version" below — this is a deliberate constraint we explain there, and we understand it limits what you can do with this report.
• I read the FAQ and programmers-guide.

---

GPU Hardware

Intel N97 (Alder Lake-N), integrated UHD Graphics (Gen12LP), 12 W package.

DRI Devices Information

crw-rw----+ 1 root video  226,   0 /dev/dri/card0
crw-rw----+ 1 root render 226, 128 /dev/dri/renderD128

GPU Detailed Information (lspci)

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-N [UHD Graphics] [8086:46d1]

Driver Version

25.18.33578.15 (clinfo reports 25.18.033578, OpenCL 3.0 NEO).

We have not tested a newer driver, and we want to be upfront about why. This is a
fielded appliance with a deliberately pinned kernel (6.8.0-124) and a security-updates-only
policy; moving the graphics stack is a qualification exercise we cannot run on this unit
right now. We understand this weakens the report. If the behaviour described below is
already known and fixed in a later release, that alone is a useful answer for us.

Installed GPU Driver Packages

intel-opencl-icd                 25.18.33578.15-1146~24.04
libigc2                          2.11.12-1146~24.04
libigc-dev                       2.11.12-1146~24.04
libigdgmm12:amd64                22.7.2-1135~24.04
libigdgmm-dev:amd64              22.7.2-1135~24.04
libze1:amd64                     1.16.1-1build1
intel-media-va-driver-non-free   24.1.0+ds1-1

Driver Installation Details

Installed from the Ubuntu 24.04 archive (apt), no PPA, no manual build.

Linux Distribution

Ubuntu 24.04.4 LTS (Noble Numbat)

Kernel Version & Boot Parameters

6.8.0-124-generic
BOOT_IMAGE=/vmlinuz-6.8.0-124-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
  vt.global_cursor_default=0 loglevel=3 systemd.show_status=false
  rd.systemd.show_status=false vt.handoff=7

Driver in use: i915.

Actual Behavior

Under sustained OpenCL load through OpenVINO's GPU plugin, the host process dies with
SIGSEGV inside libigdrcl.so roughly every 8 to 15 minutes.

The faulting instruction is always the same, and it is always a read of a pointer field:

inf.1202[386411]: segfault at fff8f60000 ip 00007f719d5edf61 sp 00007f707e82a098
    error 4 in libigdrcl.so[7f719d200000+749000]
inf.1179[389978]: segfault at fff8960000 ip 000079047c9edf61 sp 0000790426ff91b8
    error 4 in libigdrcl.so[79047c600000+749000]
inf.248[393586]:  segfault at fffe360000 ip 00007cc07fbedf61 sp 00007cc02f7fa1b8
    error 4 in libigdrcl.so[7cc07f800000+749000]

Two properties hold across every occurrence we recorded:

• The faulting addresses are not small offsets from a null pointer — they are large,
  plausible-looking values. The memory looks reused, not merely freed.
• The offset within the mapping is identical every time, which places the fault at a
  single instruction.

Resolving that offset lands in
NEO::DrmCommandStreamReceiver<Gen12LpFamily>::makeNonResident(GraphicsAllocation&),
in shared/source/os_interface/linux/drm_command_stream.inl.

The most direct reading is that the allocation is destroyed and its heap block rewritten
before makeNonResident() runs on it. We did not capture the racing free itself — we
have no ASan or Valgrind trace of the producer side. Please treat the ownership path as
our best reading, not as an established fact.

Expected Behavior

No crash. The process should keep running under sustained multi-context load.

Reproduction Rate

Consistently reproducible on this machine at high load: 14 crashes in 2 hours.
Below roughly half that load we did not observe it within a 2-hour window.

Steps to Reproduce

1. Run a pool of 2 ov::InferRequest objects (OpenVINO 2024.6, GPU plugin, THROUGHPUT)
   driven continuously from ~40 host threads.
2. Model: a small object detector, 416×416, FP32 (no INT8 quantisation).
3. Sustain ~100 inferences/s, fed by decoded video frames.
4. Wait. First crash typically within 15 minutes.

The crash rate scales with the number of concurrent input streams.

Is this a regression?

Unknown — we have only ever run this workload on this driver version.

System Logs / dmesg Output

See the segfault lines quoted under "Actual Behavior". We have the full set with
timestamps and can attach it.

Backtrace

We could not obtain a symbolised backtrace: the shipped library carries no .debug_info,
and the process dies in a worker thread. Our localisation is based on the faulting offset
within the mapping plus disassembly around it, not on a captured stack.

Source Code / Reproducer

We do not have a minimal standalone reproducer, and we recognise this is the main gap
in this report. The failure currently only manifests inside our full application
(OpenVINO + live video decode). Building a synthetic OpenCL load that reproduces it,
without our application or model, is the obvious next step and we have not managed it yet.

What we did instead, and what we can offer as evidence:

Two edits in drm_command_stream.inl:

1. In makeNonResident(): do not dereference gfxAllocation at all — only clear the
   residency container.
2. In processResidency(): after makeBOsResident, release residency for the allocations
   just processed, when this CSR owns the cleanup (no direct submission active).

Same machine, same workload, same stream count:

stock 25.18.33578.15    14 crashes in  2 hours
patched                  0 crashes in 16 hours   (29 samples, 30-minute interval)

Host memory over the 16-hour run was flat (+51 MB), so the change does not appear to leak
the residency it stops releasing eagerly.

We are not proposing this as a fix — it is a workaround shaped by our observations, and
we do not know which component is expected to keep the allocation alive here. We report it
because the before/after is the strongest signal we have that the fault is real and located
where we think it is.

Command Line / Application Details

Long-running service, no command line of interest. The OpenCL work is issued entirely
through OpenVINO's GPU plugin.

oneAPI Version

Not used. OpenVINO 2024.6 only.

---

If an instrumented build or a targeted experiment on our side would help, we are willing to
run it: the machine is available and the failure is reliable at this load.

[kgibala]

Hello @matt73200,

Thank you for your contribution.

Could you please follow the Issue Submission Guide and create an issue based on it? You can edit this one.

Thank you.

[matt73200]

Hi @kgibala, thanks for the quick response.

I have rewritten the issue following the Linux GPU Driver Issue template — system info, packages, kernel and boot parameters, reproduction rate, and logs are now in the expected fields.

Two points I want to flag honestly rather than leave you to discover them:

• I am not on the latest driver. This is a fielded appliance with a pinned kernel and a security-updates-only policy, so moving the graphics stack is not something I can do on this unit right now. If this behaviour is already known and fixed in a later release, that answer alone would be useful to me.
• I have no minimal standalone reproducer. The failure only manifests inside the full application so far. I understand this is the main gap, and building a synthetic OpenCL load that reproduces it is the obvious next step on my side.

What I do have is a before/after on the same machine and workload: 14 crashes in 2 hours on the stock library, 0 in 16 hours with the residency handling changed. Happy to run an instrumented build or a targeted experiment if that would help narrow it down.