I asked LLM to analyse the issue.
___ LLM output ___
The issue is a double-teardown race in TTM:
- In ttm_bo.c, the BO destroy path reaches
`ttm_bo_cleanup_memtype_use()` → `ttm_resource_free()` →
`ttm_resource_fini()`.
- In amdgpu_ttm.c, the move path also frees/replaces the BO’s current
resource via `ttm_resource_free()` and then `ttm_bo_assign_mem()`.
- If a BO is being moved and released concurrently, the same `struct
ttm_resource` can be torn down twice. The second teardown then hits
`list_del_init(&res->lru.link)` on an already-detached LRU entry, which
matches the `list_del corruption` warning you saw and then cascades into
the spinlock/oops.
______
At least it matches the Oops I found. I asked LLM to create a workaround
(attached) . I applied it to vanilla 7.0.14 and did not experience any
crashes now for a few days.
Not sure if the approach with the additional guard is the "right way" to
fix,
Best
Olaf
Am 16.06.26 um 11:18 schrieb Christian König:
On 6/16/26 11:12, Uwe Kleine-König wrote:
Control: forwarded -1https://lore.kernel.org/amd-gfx/ajEQr3IXQ8byLFvC@monoceros
Hello,
a Debian user reported an issue while using the amdgpu user. The full
details are available athttps://bugs.debian.org/1139599. The relvant (I
hope) parts are also in this mail, but you can find more logs there if
you want to take a look.
On Wed, Jun 10, 2026 at 09:01:09AM +0200, Olaf Flebbe wrote:
* What led up to the situation?
Heavy use of LM-Studio with local GPU accellerated models.
HW: AMD Ryzen™ 7 7840U w/ Radeon™ 780M Graphics × 16 (Framework 13
Laptop)
* What exactly did you do (or not do) that was effective (or
ineffective)?
Normal use (use gnome-calc for instance) while LM-Studio was active.
* What was the outcome of this action?
Moved the mouse: Computer totally locked, hat to power off.
* What outcome did you expect instead?
Mouse movement :)
Happend two times with Kernel reports both mentioning "ttm something" and
"amdgpu_bo_move"
@Olaf: If you still have both issues in your logs, providing both might
help to identify the issue. Also it would be great to know, how reliably
you can reproduce the issue, in case we have to resort to bisecting or
testing a fix. Is this a regression, i.e. did the same workflow work
fine before, with an older kernel version? If so, which one?
Jun 09 23:00:08 frame kernel: slab kmalloc-96 start ffff8ca660fea420 pointer
offset 64 size 96
Jun 09 23:00:08 frame kernel: list_del corruption. next->prev should be
ffff8ca661e9ed60, but was ffff8ca623eb9180. (next=ffff8ca660fea460)
Jun 09 23:00:08 frame kernel: ------------[ cut here ]------------
Jun 09 23:00:08 frame kernel: kernel BUG at lib/list_debug.c:65!
Jun 09 23:00:08 frame kernel: Oops: invalid opcode: 0000 [#1] SMP NOPTI
Jun 09 23:00:08 frame kernel: CPU: 2 UID: 1000 PID: 34294 Comm: ptyxis Not
tainted 7.0.10+deb14-amd64 #1 PREEMPT(lazy) Debian 7.0.10-1
Jun 09 23:00:08 frame kernel: Hardware name: Framework Laptop 13 (AMD Ryzen
7040Series)/FRANMDCP07, BIOS 03.19 05/21/2026
Jun 09 23:00:08 frame kernel: RIP:
0010:__list_del_entry_valid_or_report+0x10a/0x120
Jun 09 23:00:08 frame kernel: Code: 89 d7 48 89 14 24 e8 55 36 be ff 48 8b 14 24 48
8b 74 24 08 48 c7 c7 48 9f be 9f 48 8b 42 08 48 89 d1 48 89 c2 e8 f6 35 77 ff
<0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00
Jun 09 23:00:08 frame kernel: RSP: 0018:ffffd434c67a36c0 EFLAGS: 00010246
Jun 09 23:00:08 frame kernel: RAX: 000000000000006d RBX: ffff8ca661e9ed20 RCX:
0000000000000027
Jun 09 23:00:08 frame kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI:
ffff8cad5e69d2c0
Jun 09 23:00:08 frame kernel: RBP: ffff8ca60ed8f688 R08: 0000000000000000 R09:
ffffd434c67a3568
Jun 09 23:00:08 frame kernel: R10: ffffffffa04f25b0 R11: 00000000ffffefff R12:
ffff8ca60ed8ee38
Jun 09 23:00:08 frame kernel: R13: ffff8ca661e9ed60 R14: ffff8ca60ed80000 R15:
0000000000000001
Jun 09 23:00:08 frame kernel: FS: 00007fc2854a4580(0000)
GS:ffff8cadbd5fc000(0000) knlGS:0000000000000000
Jun 09 23:00:08 frame kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 09 23:00:08 frame kernel: CR2: 00007fe855d9fff0 CR3: 0000000194167000 CR4:
0000000000f50ef0
Jun 09 23:00:08 frame kernel: PKRU: 55555554
Jun 09 23:00:08 frame kernel: Call Trace:
Jun 09 23:00:08 frame kernel: <TASK>
Jun 09 23:00:08 frame kernel: ttm_resource_fini+0x34/0x70 [ttm]
Jun 09 23:00:08 frame kernel: ttm_sys_man_free+0x12/0x20 [ttm]
Jun 09 23:00:08 frame kernel: ttm_resource_free+0x9a/0xf0 [ttm]
Jun 09 23:00:08 frame kernel: amdgpu_bo_move+0xba/0x810 [amdgpu]
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? unmap_mapping_range+0x80/0x130
Jun 09 23:00:08 frame kernel: ttm_bo_handle_move_mem+0xd0/0x1a0 [ttm]
Jun 09 23:00:08 frame kernel: ttm_bo_validate+0xd8/0x180 [ttm]
Jun 09 23:00:08 frame kernel: ? __pfx_amdgpu_cs_bo_validate+0x10/0x10 [amdgpu]
Jun 09 23:00:08 frame kernel: amdgpu_cs_bo_validate+0x9a/0x1a0 [amdgpu]
Jun 09 23:00:08 frame kernel: ? __pfx_amdgpu_cs_bo_validate+0x10/0x10 [amdgpu]
Jun 09 23:00:08 frame kernel: amdgpu_vm_validate+0x31b/0x4c0 [amdgpu]
Jun 09 23:00:08 frame kernel: ? __pfx_amdgpu_cs_bo_validate+0x10/0x10 [amdgpu]
Jun 09 23:00:08 frame kernel: amdgpu_cs_parser_bos.isra.0+0x5f8/0x960 [amdgpu]
Jun 09 23:00:08 frame kernel: amdgpu_cs_ioctl+0x10a0/0x2140 [amdgpu]
Jun 09 23:00:08 frame kernel: ? __pfx_amdgpu_cs_ioctl+0x10/0x10 [amdgpu]
Jun 09 23:00:08 frame kernel: drm_ioctl_kernel+0xae/0x100 [drm]
Jun 09 23:00:08 frame kernel: drm_ioctl+0x2a8/0x550 [drm]
Jun 09 23:00:08 frame kernel: ? __pfx_amdgpu_cs_ioctl+0x10/0x10 [amdgpu]
Jun 09 23:00:08 frame kernel: amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
Jun 09 23:00:08 frame kernel: __x64_sys_ioctl+0x97/0xe0
Jun 09 23:00:08 frame kernel: do_syscall_64+0xcd/0x15f0
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? count_memcg_events+0xeb/0x220
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? handle_mm_fault+0x1d6/0x2d0
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? do_user_addr_fault+0x2b4/0x7b0
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? irqentry_exit+0x78/0x680
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: ? exc_page_fault+0x82/0x1d0
Jun 09 23:00:08 frame kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Jun 09 23:00:08 frame kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jun 09 23:00:08 frame kernel: RIP: 0033:0x7fc28abb3d3b
Jun 09 23:00:08 frame kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24
10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05
<89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
Jun 09 23:00:08 frame kernel: RSP: 002b:00007ffde5ca84a0 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
Jun 09 23:00:08 frame kernel: RAX: ffffffffffffffda RBX: 00007ffde5ca86b8 RCX:
00007fc28abb3d3b
Jun 09 23:00:08 frame kernel: RDX: 00007ffde5ca8540 RSI: 00000000c0186444 RDI:
0000000000000013
Jun 09 23:00:08 frame kernel: RBP: 00007ffde5ca8580 R08: 00005638df61a860 R09:
00007ffde5ca8500
Jun 09 23:00:08 frame kernel: R10: 0000000000000000 R11: 0000000000000246 R12:
00005638df61a800
Jun 09 23:00:08 frame kernel: R13: 0000000000000013 R14: 0000086559c3e8fb R15:
00005638df832620
Jun 09 23:00:08 frame kernel: </TASK>
Jun 09 23:00:08 frame kernel: Modules linked in: overlay sd_mod scsi_mod
scsi_common rfcomm snd_seq_dummy snd_hrtimer snd_seq xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat x_tables
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables
bridge stp llc ccm uhid cmac algif_hash algif_skcipher af_alg qrtr bnep
nls_ascii nls_cp437 vfat fat amd_atl intel_rapl_msr intel_rapl_common
edac_mce_amd snd_sof_amd_rembrandt kvm_amd snd_sof_amd_acp snd_sof_pci
snd_sof_xtensa_dsp snd_sof kvm snd_sof_utils snd_pci_ps snd_soc_acpi_amd_match
uvcvideo hid_sensor_als snd_soc_acpi_amd_sdca_quirks hid_sensor_trigger
snd_amd_sdw_acpi videobuf2_vmalloc soundwire_amd irqbypass
hid_sensor_iio_common iwlmvm soundwire_generic_allocation uvc kfifo_buf btusb
rapl soundwire_bus industrialio videobuf2_memops btmtk videobuf2_v4l2
leds_cros_ec snd_soc_sdca snd_hda_codec_alc269 btrtl wmi_bmof cros_ec_hwmon
led_class_multicolor snd_hda_codec_realtek_lib videodev snd_hda_codec_atihdmi
btbcm mac80211 snd_soc_core
Jun 09 23:00:08 frame kernel: snd_hda_codec_hdmi btintel
snd_hda_scodec_component pcspkr videobuf2_common snd_compress
snd_hda_codec_generic bluetooth libarc4 snd_pcm_dmaengine snd_usb_audio k10temp
snd_rpl_pci_acp6x spd5118 snd_hda_intel snd_usbmidi_lib ecdh_generic
snd_acp_pci snd_hda_codec snd_amd_acpi_mach snd_hda_core snd_rawmidi
snd_intel_dspcfg snd_acp_legacy_common snd_seq_device snd_intel_sdw_acpi
snd_pci_acp6x mc snd_hwdep iwlwifi amdxdna snd_pcm snd_pci_acp5x snd_timer
amd_pmf snd_rn_pci_acp3x drm_shmem_helper snd_acp_config cfg80211 amdtee snd
snd_soc_acpi snd_pci_acp3x soundcore rfkill ccp ac amd_sfh joydev tee
platform_profile amd_pmc evdev binfmt_misc lp parport_pc ppdev parport msr
i2c_dev configfs efi_pstore nfnetlink efivarfs autofs4 ext4 mbcache jbd2
crc32c_cryptoapi r8153_ecm cdc_ether usbnet r8152 mii dm_crypt dm_mod amdgpu
usbhid amdxcp drm_panel_backlight_quirks gpu_sched drm_buddy drm_ttm_helper ttm
drm_exec i2c_algo_bit drm_suballoc_helper ucsi_acpi drm_display_helper
typec_ucsi hid_multitouch typec
Jun 09 23:00:08 frame kernel: hid_sensor_hub cec hid_generic roles rc_core
i2c_hid_acpi drm_client_lib i2c_hid cros_ec_debugfs hid cros_ec_chardev
cros_charge_control cros_ec_sysfs drm_kms_helper cros_kbd_led_backlight nvme
xhci_pci ghash_clmulni_intel cros_ec_dev xhci_hcd nvme_core aesni_intel
serio_raw drm sp5100_tco nvme_keyring battery watchdog thunderbolt usbcore
nvme_auth cros_ec_lpcs video crc16 hkdf cros_ec i2c_piix4 cros_ec_proto wmi
button i2c_smbus usb_common
Jun 09 23:00:08 frame kernel: ---[ end trace 0000000000000000 ]---
I didn't find a similar report on lore.kernel.org. Does this ring a bell
for you anyhow?
That looks familiar, yes.
Just last night Samuel Ainsworth reported some bug in TTM which could trigger
such issues. Putting him on CC.
Regards,
Christian.
There are a few amdgpu changes in 7.0.11 (since 7.0.10 which is the
kernel that showed the issue), but they don't look (to me that is) as if
they would resolve the problem.
Best regards
Uwe
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c
index bfd9c68fcd9c..b065b1aba435 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -352,6 +352,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
res->bus.is_iomem = false;
res->bus.caching = ttm_cached;
res->bo = bo;
+ res->flags = 0;
man = ttm_manager_type(bo->bdev, place->mem_type);
spin_lock(&bo->bdev->lru_lock);
@@ -380,8 +381,11 @@ void ttm_resource_fini(struct ttm_resource_manager *man,
struct ttm_device *bdev = man->bdev;
spin_lock(&bdev->lru_lock);
+ if (list_empty(&res->lru.link))
+ goto out;
list_del_init(&res->lru.link);
man->usage -= res->size;
+out:
spin_unlock(&bdev->lru_lock);
}
EXPORT_SYMBOL(ttm_resource_fini);
@@ -425,17 +429,24 @@ void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource **res)
{
struct ttm_resource_manager *man;
struct dmem_cgroup_pool_state *pool;
+ struct ttm_resource *resource;
if (!*res)
return;
+ resource = *res;
+ if (test_and_set_bit(TTM_RESOURCE_FLAG_FREED, &resource->flags))
+ return;
+
+ *res = NULL;
+
spin_lock(&bo->bdev->lru_lock);
- ttm_resource_del_bulk_move(*res, bo);
+ ttm_resource_del_bulk_move(resource, bo);
spin_unlock(&bo->bdev->lru_lock);
- pool = (*res)->css;
- man = ttm_manager_type(bo->bdev, (*res)->mem_type);
- man->func->free(man, *res);
+ pool = resource->css;
+ man = ttm_manager_type(bo->bdev, resource->mem_type);
+ man->func->free(man, resource);
*res = NULL;
if (man->cg)
dmem_cgroup_uncharge(pool, bo->base.size);
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index a5d386583fb6..1a58c0c000c5 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -30,6 +30,7 @@
#include <linux/mutex.h>
#include <linux/iosys-map.h>
#include <linux/dma-fence.h>
+#include <linux/bitops.h>
#include <drm/ttm/ttm_caching.h>
#include <drm/ttm/ttm_kmap_iter.h>
@@ -37,6 +38,8 @@
#define TTM_MAX_BO_PRIORITY 4U
#define TTM_NUM_MEM_TYPES 9
+#define TTM_RESOURCE_FLAG_FREED BIT(0)
+
struct dentry;
struct dmem_cgroup_device;
struct drm_printer;
@@ -270,6 +273,8 @@ struct ttm_resource {
struct dmem_cgroup_pool_state *css;
+ unsigned long flags;
+
/**
* @lru: Least recently used list, see &ttm_resource_manager.lru
*/
