[Nouveau] swiotlb buffer is full

[Christian König]

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 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