Bug 1089998

Summary: radeon: swiotlb buffer is full
Product: [openSUSE] openSUSE Tumbleweed Reporter: Gary Ching-Pang Lin <glin>
Component: KernelAssignee: E-mail List <kernel-maintainers>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: tiwai
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Gary Ching-Pang Lin 2018-04-18 08:23:12 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
Comment 1 Gary Ching-Pang Lin 2018-04-18 08:28:21 UTC
Found the upstream bug about the trace:
https://bugs.freedesktop.org/show_bug.cgi?id=104082
Comment 2 Takashi Iwai 2018-04-18 08:56:12 UTC
Already fixed in the latest stable branch.

*** This bug has been marked as a duplicate of bug 1088902 ***
Comment 3 Gary Ching-Pang Lin 2018-04-18 10:00:52 UTC
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.
Comment 4 Takashi Iwai 2018-04-18 11:22:47 UTC
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.
Comment 5 Gary Ching-Pang Lin 2018-04-19 02:18:36 UTC
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.
Comment 6 Gary Ching-Pang Lin 2018-04-19 02:38:59 UTC
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.