* swiotlb buffer is full
@ 2018-01-31 16:05 Ricardo Nabinger Sanchez
2018-02-01 2:20 ` Ilia Mirkin
0 siblings, 1 reply; 4+ messages in thread
From: Ricardo Nabinger Sanchez @ 2018-01-31 16:05 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: swiotlb buffer is full
2018-01-31 16:05 swiotlb buffer is full Ricardo Nabinger Sanchez
@ 2018-02-01 2:20 ` Ilia Mirkin
2018-02-01 2:25 ` [Nouveau] " Alex Deucher
0 siblings, 1 reply; 4+ messages in thread
From: Ilia Mirkin @ 2018-02-01 2:20 UTC (permalink / raw)
To: Ricardo Nabinger Sanchez, Christian König; +Cc: nouveau, dri-devel
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@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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Nouveau] swiotlb buffer is full
2018-02-01 2:20 ` Ilia Mirkin
@ 2018-02-01 2:25 ` Alex Deucher
2018-02-01 9:20 ` Christian König
0 siblings, 1 reply; 4+ messages in thread
From: Alex Deucher @ 2018-02-01 2:25 UTC (permalink / raw)
To: Ilia Mirkin
Cc: nouveau, dri-devel, Christian König, Ricardo Nabinger Sanchez
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Nouveau] swiotlb buffer is full
2018-02-01 2:25 ` [Nouveau] " Alex Deucher
@ 2018-02-01 9:20 ` Christian König
0 siblings, 0 replies; 4+ messages in thread
From: Christian König @ 2018-02-01 9:20 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Konrad Rzeszutek Wilk
Cc: nouveau, dri-devel, Ricardo Nabinger Sanchez
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-02-01 9:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-31 16:05 swiotlb buffer is full Ricardo Nabinger Sanchez
2018-02-01 2:20 ` Ilia Mirkin
2018-02-01 2:25 ` [Nouveau] " Alex Deucher
2018-02-01 9:20 ` Christian König
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.