Re: kernel spew from nouveau/ swiotlb
From: Mike Galbraith
Date: Fri May 11 2018 - 03:15:04 EST
On Thu, 2018-05-10 at 12:28 +0200, Mike Galbraith wrote:
> On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote:
> > Greetings,
> >
> > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The
> > below is from master.today.
> >
> > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12594.693000] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12594.713787] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12594.743413] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12594.796740] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12607.000774] swiotlb_tbl_map_single: 54 callbacks suppressed
> > [12607.000776] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12607.347941] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > [12608.677038] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
> > homer:/novell/ssh # dmesg|grep 'swiotlb buffer is full'|wc -l
> > 2052
> > homer:/novell/ssh # dmesg|grep 'callbacks suppressed'|wc -l
> > 171
> >
> > lib/swiotlb.c:
> > 573 not_found:
> > 574 spin_unlock_irqrestore(&io_tlb_lock, flags);
> > 575 if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit())
> > 576 dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n", size);
> >
> > Does nouveau perhaps want one of those DMA_ATTR_NO_WARN thingies?
>
> Or should ttm perhaps always use the one on hand? (seems to work)
No it didn't, I just didn't wait long enough for spew to start...
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -342,7 +342,7 @@ static struct dma_page *__ttm_dma_alloc_
> if (!d_page)
> return NULL;
>
> - if (pool->type & IS_HUGE)
> + if (1 || pool->type & IS_HUGE)
> attrs = DMA_ATTR_NO_WARN;
>
> vaddr = dma_alloc_attrs(pool->dev, pool->size, &d_page->dma,
While IS_HUGE is indeed false on my box, it just doesn't matter,
because when we get to either the old or the new alloc(), it calls
swiotlb_alloc_buffer(), which drops attrs passed to it on the floor,
making it unlikely that alloc() caller wishes are granted.
-Mike