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."
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? -ilia On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez <rnsanchez at 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 at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin <imirkin at 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 at 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 at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel