Displaying 4 results from an estimated 4 matches for "swiotlb_alloc_buff".
Did you mean:
swiotlb_alloc_buffer
2018 May 10
1
kernel spew from nouveau/ swiotlb
...a_pool_alloc_new_pages()
dma_alloc_attrs()
ops->alloc() == x86_swiotlb_alloc_coherent()
x86_swiotlb_alloc_coherent() flags |= __GFP_NOWARN;
swiotlb_alloc_coherent(..flags)
swiotlb_alloc_coherent(..flags) attrs = (flags & __GFP_NOWARN) ? DMA_ATTR_NO_WARN : 0;
swiotlb_alloc_buffer(..attr)
swiotlb_alloc_buffer(..0) <== hm, pass zero instead of attr?
swiotlb_tbl_map_single() gripeage
...that?
-Mike
2018 May 11
2
kernel spew from nouveau/ swiotlb
...+ 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
2018 May 10
4
kernel spew from nouveau/ swiotlb
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
2018 May 11
0
[patch] swiotlb: fix ignored DMA_ATTR_NO_WARN request
In the trace below, swiotlb_alloc() is called with __GFP_NOWARN, it ors
attrs with DMA_ATTR_NO_WARN and passes it to swiotlb_alloc_buffer(),
which does NOT pass it on to swiotlb_tbl_map_single(), leading to an
ever repeating warning that the caller of swiotlb_alloc() explicitly
asked to be squelched. Pass the caller's request for silence onward.
Xorg-3170 [006] .... 963.866098: swiotlb_alloc+0x1d/0x1a0: gfp & __GFP_NO...