Hi!

This is my first time submitting a debian bug report. Full
disclosure: I used Claude Opus-5.5 to characterize the bug and find
out that it is fixed upstream.  Below is the report claude generated
with the upstream patch. I read it and checked that the bug does
seem to have been reported and fixed upstream (Mesa 25.2.0), which
is in sid and trixie-backports, but trixie is still on 25.0.7-2. I
personally know nothing at all about GPU drivers. Sorry I can't be
more helpful. I hope this report is helpful and not annoying.

Nathan TeBlunthuis

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The iris driver in trixie can permanently deadlock any GL client on Gen12+
Intel GPUs. The bug was reported and fixed upstream (Mesa issue #13241, MR
!35266, commit 6f283645416ca5e67ff57dcc3b187057675945ca). The fix first shipped
in Mesa 25.2.0 and was never backported to the 25.0 branch, so trixie's
25.0.7-2+deb13u1 is still affected. testing/unstable (26.x) and
trixie-backports (26.1.6-1~bpo13+1) are not.

Mechanism (from the upstream report): iris_bo_alloc() takes the bufmgr
simple_mtx. When it reuses a BO from the cache, alloc_bo_from_cache() calls
intel_aux_map_unmap_range(). If the range covers aux-table pages that were
never created, get_aux_entry() creates them via add_sub_table() ->
intel_aux_map_buffer_alloc(), which tries to take the same bufmgr lock again.
The thread waits on itself forever. Every other thread that later needs the
lock blocks as well. CPU use drops to zero and nothing recovers; the process
has to be killed. Upstream reports the X server hanging within minutes to hours
when many windows are open.

Observed here: Firefox 159.0 (Mozilla binary, Wayland, sway) froze completely
while loading a large SVG. gdb on the parent process, with libgallium frames
symbolicated against the Debian debug symbols, shows the same stack as the
upstream report:

  Thread "Renderer" (WebRender)
    futex_wait                         src/util/futex.c:57
    intel_aux_map_buffer_alloc         src/gallium/drivers/iris/iris_bufmgr.c:2237
    add_sub_table                      src/intel/common/intel_aux_map.c:337
    get_aux_entry                      src/intel/common/intel_aux_map.c:557
    remove_mapping_locked              src/intel/common/intel_aux_map.c:696
    intel_aux_map_unmap_range          src/intel/common/intel_aux_map.c:759
    alloc_bo_from_cache                src/gallium/drivers/iris/iris_bufmgr.c:1071
    iris_bo_alloc                      src/gallium/drivers/iris/iris_bufmgr.c:1253
    iris_resource_create_for_image     src/gallium/drivers/iris/iris_resource.c:1174
    st_texture_create                  src/mesa/state_tracker/st_texture.c:110
    st_texture_storage                 src/mesa/state_tracker/st_cb_texture.c:3504
    st_AllocTextureStorage             src/mesa/state_tracker/st_cb_texture.c:3561
    texture_storage_error              src/mesa/main/texstorage.c:648
    texstorage_error                   src/mesa/main/texstorage.c:705
    _mesa_TexStorage2D                 src/mesa/main/texstorage.c:814
    [webrender create_texture -> update_texture_cache -> render]

  Thread "CanvasRenderer" (WebGL), waiting on the same futex address
    futex_wait                         src/util/futex.c:57
    iris_bo_unreference                src/gallium/drivers/iris/iris_bufmgr.c:1667
    iris_batch_reset                   src/gallium/drivers/iris/iris_batch.c:474
    _iris_batch_flush                  src/gallium/drivers/iris/iris_batch.c:992
    iris_fence_flush                   src/gallium/drivers/iris/iris_fence.c:265
    tc_flush                           src/gallium/auxiliary/util/u_threaded_context.c:3597
    st_glFlush                         src/mesa/state_tracker/st_cb_flush.c:102

The Firefox main and compositor threads were blocked behind the Renderer
thread. The kernel logged no GPU hang or reset. The trigger is any texture or
buffer allocation that hits this BO-cache path, not something specific to
Firefox or SVG.

The upstream patch is a 15-line change to src/intel/common/intel_aux_map.c
that adds a `create` flag to get_aux_entry(), so the removal path never
allocates table pages. It applies cleanly to the mesa-25.0.7 tag
(`patch -p1 --dry-run`, no offsets or fuzz). I have not built or run-tested the
patched package. I'd ask that it be considered for a trixie point release; it
is included below.

System:
  Debian 13.7 (trixie), amd64; sway 1.12-1 from unstable
  Kernel 7.0.13+deb13-amd64 (7.0.13-1~bpo13+1)
  Lenovo ThinkPad X1 Carbon Gen 10, Intel Core i7-1280P
  GPU: Intel Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c)
  mesa-libgallium, libgl1-mesa-dri, libegl-mesa0, libglx-mesa0, libgbm1,
  mesa-vulkan-drivers: 25.0.7-2+deb13u1
Fixes #13241, where iris_bufmgr occasionally deadlocks while allocating buffers.

The deadlock happens when iris_bufmgr.c calls intel_aux_map_unmap_range while
holding the bufmgr lock, with a range that includes pages that were never created,
which can happen because the iris_resource that adds aux mappings will sometimes
use a slightly larger buffer with an offset to ensure the resource is aligned
correctly.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35266>
---
 src/intel/common/intel_aux_map.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/src/intel/common/intel_aux_map.c b/src/intel/common/intel_aux_map.c
index 4f10fc6ecbf4..63c062e37de0 100644
--- a/src/intel/common/intel_aux_map.c
+++ b/src/intel/common/intel_aux_map.c
@@ -515,11 +515,12 @@ get_l1_addr_mask(struct intel_aux_map_context *ctx)
    return l1_addr & VALID_ADDRESS_MASK;
 }