Re: [Nouveau] swiotlb buffer is full

From: Alex Deucher <alexdeucher@gmail.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: nouveau <nouveau@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Ricardo Nabinger Sanchez" <rnsanchez@gmail.com>
Subject: Re: [Nouveau] swiotlb buffer is full
Date: Wed, 31 Jan 2018 21:25:22 -0500	[thread overview]
Message-ID: <CADnq5_N7GraJHq2mugMkGSyav_qaO5=Rj+Acm+8brzdAT_oaGA@mail.gmail.com> (raw)
In-Reply-To: <CAKb7UvjG3302K+YEEuoU91ait0BKxGuh+avqMgo7q2cC6GUF5w@mail.gmail.com>

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