Bugzilla – Bug 1089998
radeon: swiotlb buffer is full
Last modified: 2018-04-19 02:38:59 UTC
While using libreoffice draw to edit slides, it became very slow and took around 5 seconds to get the focus of a object. I found there were a lot of trace in dmesg, and it probably caused the slowness. The similar traces repeated several times: [11455.911766] radeon 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [11455.911767] radeon 0000:01:00.0: swiotlb: coherent allocation failed, size=2097152 [11455.911770] CPU: 6 PID: 2154 Comm: X Not tainted 4.16.1-1-default #1 openSUSE Tumbleweed (unreleased) [11455.911770] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A12 05/06/2015 [11455.911771] Call Trace: [11455.911777] dump_stack+0x85/0xc5 [11455.911780] swiotlb_alloc_coherent+0x1b6/0x1d0 [11455.911786] ttm_dma_pool_get_pages+0x1ed/0x5b0 [ttm] [11455.911790] ttm_dma_populate+0x25e/0x350 [ttm] [11455.911792] ttm_tt_bind+0x2c/0x60 [ttm] [11455.911795] ttm_bo_handle_move_mem+0x577/0x5b0 [ttm] [11455.911798] ttm_bo_validate+0x100/0x110 [ttm] [11455.911810] ? drm_vma_offset_add+0x41/0x60 [drm] [11455.911816] ? drm_mode_connector_list_update+0x13e/0x170 [drm] [11455.911818] ttm_bo_init_reserved+0x382/0x430 [ttm] [11455.911821] ttm_bo_init+0x52/0xc0 [ttm] [11455.911833] ? radeon_update_memory_usage.isra.4+0x50/0x50 [radeon] [11455.911841] radeon_bo_create+0x180/0x240 [radeon] [11455.911849] ? radeon_update_memory_usage.isra.4+0x50/0x50 [radeon] [11455.911858] radeon_gem_object_create+0x93/0x180 [radeon] [11455.911866] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [11455.911874] radeon_gem_create_ioctl+0x56/0xf0 [radeon] [11455.911876] ? unix_stream_recvmsg+0x43/0x50 [11455.911883] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [11455.911888] drm_ioctl_kernel+0x5b/0xb0 [drm] [11455.911894] drm_ioctl+0x2ad/0x350 [drm] [11455.911901] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [11455.911903] ? do_iter_write+0xdc/0x190 [11455.911904] ? vfs_writev+0xaa/0xf0 [11455.911910] radeon_drm_ioctl+0x49/0x80 [radeon] [11455.911912] do_vfs_ioctl+0x90/0x5f0 [11455.911914] ? __sys_recvmsg+0x5d/0x70 [11455.911916] ? __fget+0x6e/0xb0 [11455.911917] SyS_ioctl+0x74/0x80 [11455.911919] do_syscall_64+0x76/0x140 [11455.911921] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [11455.911922] RIP: 0033:0x7fcd93f5a967 [11455.911923] RSP: 002b:00007ffc8bcf7528 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [11455.911924] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fcd93f5a967 [11455.911925] RDX: 00007ffc8bcf75a0 RSI: 00000000c020645d RDI: 0000000000000010 [11455.911925] RBP: 00007ffc8bcf75a0 R08: 0000000000000002 R09: 0000000000000000 [11455.911926] R10: 0000000000334000 R11: 0000000000000246 R12: 00000000c020645d [11455.911926] R13: 0000000000000010 R14: 0000561254c21440 R15: 0000000000000002
Found the upstream bug about the trace: https://bugs.freedesktop.org/show_bug.cgi?id=104082
Already fixed in the latest stable branch. *** This bug has been marked as a duplicate of bug 1088902 ***
Confirmed the trace was gone after upgrading to 4.16.2 in kernel:stable. However, libreoffice is still slow, so the trace is not relevant.
Just to be sure, could you try also the kernel in OBS home:tiwai:bnc1088902 repo? I guess it won't change the behavior, and the cause is unlikely relevant with the memory allocation, but still worth to try.
I tried flatpak libreoffice 6.0.3.2 and it works very well so it's likely to be a problem in the userspace software stack.
Well, it's stranger than I thought. I removed gtk-font-name from .gtkrc-2.0 and .config/gtk-3.0/settings.ini and libreoffice becomes responsive again.