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@alum.mit.edu 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@gmail.com 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel