-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Package: mesa-libgallium
Version: 25.0.7-2+deb13u1
Severity: important
Tags: patch upstream fixed-upstream trixie
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/13241
Control: fixed -1 25.2.0-1
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
- -----8<----- upstream commit 6f283645 -----8<-----
- From 6f283645416ca5e67ff57dcc3b187057675945ca Mon Sep 17 00:00:00 2001
From: Calder Young <[email protected]>
Date: Mon, 2 Jun 2025 12:02:20 -0700
Subject: [PATCH] intel_aux_map: Avoid creating new table pages when removing
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 <[email protected]>
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;
}
- -static void
+static bool
get_aux_entry(struct intel_aux_map_context *ctx, uint64_t main_address,
uint32_t *l1_index_out, uint64_t *l1_entry_addr_out,
uint64_t **l1_entry_map_out,
- - struct intel_aux_level **l1_aux_level_out)
+ struct intel_aux_level **l1_aux_level_out,
+ bool create)
{
struct intel_aux_level *l3_level = ctx->l3_level;
struct intel_aux_level *l2_level;
@@ -528,6 +529,8 @@ get_aux_entry(struct intel_aux_map_context *ctx, uint64_t
main_address,
uint32_t l3_index = (main_address >> 36) & 0xfff;
if (l3_level->children[l3_index] == NULL) {
+ if (!create)
+ return false;
l2_level =
add_sub_table(ctx, ctx->l3_level, l3_index,
L3_L2_SUB_TABLE_LEN, L3_L2_SUB_TABLE_LEN);
@@ -546,6 +549,8 @@ get_aux_entry(struct intel_aux_map_context *ctx, uint64_t
main_address,
uint32_t l2_index = (main_address >> 24) & 0xfff;
uint64_t l1_page_size = ctx->format->l1_page_size;
if (l2_level->children[l2_index] == NULL) {
+ if (!create)
+ return false;
l1_level = add_sub_table(ctx, l2_level, l2_index, l1_page_size,
l1_page_size);
if (l1_level != NULL) {
if (aux_map_debug)
@@ -569,6 +574,7 @@ get_aux_entry(struct intel_aux_map_context *ctx, uint64_t
main_address,
*l1_entry_map_out = &l1_level->entries[l1_index];
if (l1_aux_level_out)
*l1_aux_level_out = l1_level;
+ return true;
}
static bool
@@ -583,7 +589,8 @@ add_mapping(struct intel_aux_map_context *ctx, uint64_t
main_address,
uint32_t l1_index;
uint64_t *l1_entry;
struct intel_aux_level *l1_aux_level;
- - get_aux_entry(ctx, main_address, &l1_index, NULL, &l1_entry,
&l1_aux_level);
+ get_aux_entry(ctx, main_address, &l1_index, NULL, &l1_entry,
+ &l1_aux_level, true);
const uint64_t l1_data =
(aux_address & intel_aux_get_meta_address_mask(ctx)) |
@@ -634,7 +641,8 @@ intel_aux_map_get_entry(struct intel_aux_map_context *ctx,
{
pthread_mutex_lock(&ctx->mutex);
uint64_t *l1_entry_map;
- - get_aux_entry(ctx, main_address, NULL, aux_entry_address, &l1_entry_map,
NULL);
+ get_aux_entry(ctx, main_address, NULL, aux_entry_address, &l1_entry_map,
+ NULL, true);
pthread_mutex_unlock(&ctx->mutex);
return l1_entry_map;
@@ -653,7 +661,9 @@ remove_l1_mapping_locked(struct intel_aux_map_context *ctx,
uint64_t main_addres
uint32_t l1_index;
uint64_t *l1_entry;
struct intel_aux_level *l1_aux_level;
- - get_aux_entry(ctx, main_address, &l1_index, NULL, &l1_entry,
&l1_aux_level);
+ if (!get_aux_entry(ctx, main_address, &l1_index, NULL, &l1_entry,
+ &l1_aux_level, false))
+ return;
const uint64_t current_l1_data = *l1_entry;
const uint64_t l1_data = current_l1_data & ~INTEL_AUX_MAP_ENTRY_VALID_BIT;
- --
GitLab
To:
Subject:
Fcc: gmail_sent
- --text follows this line--
- --
Nathan TeBlunthuis
Assistant Professor, Information
School of Computing
The University of Texas at Austin
https://teblunthuis.cc
Recent highlight papers by me and collaborators:
๐ AI Didn't Start the Fire: Examining the Stack Exchange
Moderator and Contributor Strike โ CSCW 2026.
https://dl.acm.org/doi/full/10.1145/3788040
๐ The Relational Origins of Rules in Online Communities โ CSCW
2026. โ CSCW 2026. https://dl.acm.org/doi/10.1145/3817015
๐ Niche Dynamics in Complex Online Community Ecosystems
โ International AAAI Conference on Web and Social Media โ ICWSM 2025.
https://ojs.aaai.org/index.php/ICWSM/article/download/35907/38061
๐ โMisclassification in Automated Content Analysis Causes Bias in
Regression. Can We Fix It? Yes We Can!โ โ Communication Methods
and Measures. https://doi.org/10.1080/19312458.2023.2293713.
-----BEGIN PGP SIGNATURE-----
iQJQBAEBCgA6FiEEIprzAqpraa9iMKUPYHrYPcMjPaEFAmrs6TocHG5hdGhhbnRl
Ymx1bnRodWlzQGdtYWlsLmNvbQAKCRBgetg9wyM9obWdEACTsc43D11XZ1pHScdu
WsoXJ9axbMMPkDGJO2rBENGFRFCIiRq2dq3R8zl+PlWWQ3HIyNnhTn73Pp/+JPKG
cu2FZKfBL8A9nYjUYf2Nawx3WRa9ykz8/KM5kxX4JmMPV6r0M6PRFyzYyNnJT7zu
7F8JDbNvN64t1tCLZF2W3lJiHuVK8haza9+gNLfqsFPR4h8GEvpiLb+svVX/PzFS
XUMbUKfOS8POHquvPo7yQWPmVJNlk1Xvnxhfy/lP7iJ28SPWEjHiyLDKEnfAN7/d
MwFX6czaHCT4GE9a5BfN2867ocXZwf9E8KUL86agYEXFANX5vewOsWeUmPU7WeVD
rPP/wo266N/v76QtBZZdVVQ+7x8lEnrCz6rzLj3WexdQzJL9so2TTXTSzYxrlnf6
2OM4ErYFdrqCfwtk7myoyt705CV5Pi/v0WcriC2jLwrqXa7xcb5Fe/w0zo1cGrlV
4Li4A/lyU+PvXmRjoF0X68TY8jiNDxeozb/IWTtXn1zLe0zPdlwvZKSXL2VRIfNs
FXbB8LacmqEGOfCUHGpb2QaRP/EJ2nmq3jPhJCsYgiMrRlt7zpXeOMmvPD0Y53xi
GUv9vKAqAJzOiEUNePGOyeanQuAKgaBXDEogw0l4vKgvz8p3NCRN3uwtpQmVNpq3
hbyoYRbYBZZffob+mqws+Cb/6g==
=Yz3D
-----END PGP SIGNATURE-----
