Hi Konrad,
just a gentle ping.
It looks like the patch "swiotlb: suppress warning when __GFP_NOWARN is
set" didn't made it into 4.15 and now people are bombarding us with bug
reports about that.
Did you already send that one out for inclusion in 4.16? It also has a
stable tag, so it should be backported to 4.15.x once it lands in Linus
tree.
Thanks in advance,
Christian.
Am 01.02.2018 um 03:25 schrieb Alex Deucher:
On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote:
Yeah, a lot of people were getting that, as a result of some drm/ttm
hugepage usage.
Christian, did a fix ever end up going out? If so, what kernel was it
included in?
https://lkml.org/lkml/2018/1/16/106
Alex
-ilia
On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez
<rnsanchez@xxxxxxxxx> wrote:
Hello,
I've noticed firefox got randomly stuck, and as sometimes that leads to a
complete system lock-up, I've checked dmesg and got this:
[Jan29 10:49] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ +0.000033] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
[ +0.000004] CPU: 6 PID: 1023 Comm: Xorg Not tainted 4.15.0-rc8 #1
[ +0.000003] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ +0.000003] Call Trace:
[ +0.000009] dump_stack+0x9f/0xe1
[ +0.000008] swiotlb_alloc_coherent+0xdf/0x150
[ +0.000010] ttm_dma_pool_get_pages+0x1ec/0x4b0
[ +0.000015] ttm_dma_populate+0x24c/0x340
[ +0.000011] ttm_tt_bind+0x23/0x50
[ +0.000006] ttm_bo_handle_move_mem+0x58c/0x5c0
[ +0.000015] ttm_bo_validate+0x152/0x190
[ +0.000004] ? ttm_bo_init_reserved+0x3d8/0x490
[ +0.000012] ? mutex_trylock+0xcd/0xe0
[ +0.000004] ? ttm_bo_handle_move_mem+0x58/0x5c0
[ +0.000007] ttm_bo_init_reserved+0x3f4/0x490
[ +0.000010] ttm_bo_init+0x2f/0xa0
[ +0.000009] ? nouveau_bo_invalidate_caches+0x10/0x10
[ +0.000005] nouveau_bo_new+0x416/0x590
[ +0.000007] ? nouveau_bo_invalidate_caches+0x10/0x10
[ +0.000009] ? nouveau_gem_new+0x100/0x100
[ +0.000004] nouveau_gem_new+0x49/0x100
[ +0.000009] nouveau_gem_ioctl_new+0x41/0xc0
[ +0.000009] drm_ioctl_kernel+0x59/0xb0
[ +0.000008] drm_ioctl+0x2c1/0x350
[ +0.000007] ? nouveau_gem_new+0x100/0x100
[ +0.000012] ? _raw_spin_unlock_irqrestore+0x4d/0x90
[ +0.000006] ? preempt_count_sub+0x9b/0xd0
[ +0.000005] ? _raw_spin_unlock_irqrestore+0x6b/0x90
[ +0.000008] nouveau_drm_ioctl+0x64/0xc0
[ +0.000009] do_vfs_ioctl+0x8e/0x690
[ +0.000007] ? __fget+0x116/0x200
[ +0.000010] SyS_ioctl+0x74/0x80
[ +0.000009] entry_SYSCALL_64_fastpath+0x23/0x9a
[ +0.000004] RIP: 0033:0x7f7860c70727
[ +0.000003] RSP: 002b:00007ffcb0d3b088 EFLAGS: 00000246
Uptime is about 14 days now and I don't think I've seen this trace before.
Is this useful/worth chasing?
Cheers,
--
Ricardo Nabinger Sanchez http://rnsanchez.wait4.org/
"You never learned anything by doing it right."
_______________________________________________
Nouveau mailing list
Nouveau@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/nouveau
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
