similar to: [vhost:linux-next 3/23] include/linux/swiotlb.h:105:20: error: static declaration of 'is_swiotlb_active' follows non-static declaration

From: Joerg Roedel <jroedel at suse.de> This function will be used from dma_direct code to determine the maximum segment size of a dma mapping. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Reviewed-by: Christoph Hellwig <hch at lst.de> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- include/linux/swiotlb.h | 6 ++++++ kernel/dma/swiotlb.c | 9

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 104f89a60ef5ec77d6f559eac4676844b3480740 commit: 951a381d4c0d45a9b44de30228c6ef17083854ea [2/23] swiotlb: Introduce swiotlb_max_mapping_size() config: i386-tinyconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: git checkout 951a381d4c0d45a9b44de30228c6ef17083854ea #

Hi, here is the next version of this patch-set. Previous versions can be found here: V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ V3: https://lore.kernel.org/lkml/20190123163049.24863-1-joro at 8bytes.org/ V4: https://lore.kernel.org/lkml/20190129084342.26030-1-joro at 8bytes.org/

Drivers have no business looking at dma-mapping or swiotlb internals. Signed-off-by: Christoph Hellwig <hch at lst.de> --- kernel/dma/swiotlb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index af2e304c672c43..9f1fd28264a067 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -921,7 +921,6 @@ bool is_swiotlb_active(struct

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

Drivers have no business looking into dma-mapping internals and check what backend is used. Unfortunstely the DRM core is still broken and tries to do plain page allocations instead of using DMA API allocators by default and uses various bandaids on when to use dma_alloc_coherent. Switch nouveau to use the same (broken) scheme as amdgpu and radeon to remove the last driver user of

The following changes since commit 1c163f4c7b3f621efff9b28a47abb36f7378d783: Linux 5.0 (2019-03-03 15:21:29 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to cfdbb4ed31aa777d59b288810f66eb06249ee5b7: vhost: silence an unused-variable warning (2019-03-06 11:32:37 -0500)

From: Joerg Roedel <jroedel at suse.de> The function returns the maximum size that can be mapped using DMA-API functions. The patch also adds the implementation for direct DMA and a new dma_map_ops pointer so that other implementations can expose their limit. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Reviewed-by: Christoph Hellwig <hch at lst.de>

Dear nouveau mailing list, on my notebook with the GeForce GT 240M graphics card, I am failing to start sddm since linux kernel 6.5.0. The screen typically goes black or white, mouse pointer is typically visible and can be moved. This happens about 90% of times I try to start the system; in about 10%, everything works fine. If the start fails, dmesg shows output such as: [?? 20.260153] nouveau

On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=7c06047f622c5724 >

Hi all, this little series removes the last swiotlb API exposed to modules. Diffstat: arch/x86/include/asm/xen/swiotlb-xen.h | 6 ------ arch/x86/kernel/pci-dma.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++------- drivers/pci/xen-pcifront.c | 6 ------ kernel/dma/swiotlb.c | 1 - 5 files changed, 7

Greetings, Box is i4790 w. GTX 980 running virgin master (.today). All I have to do to trigger a slew of these warnings is to fire up firefox, point it at a youtube clip, and let it autoplay while I do routine kernel merge/build maintenance. nouveau doesn't seem to care deeply, but moans again and again and again... 726 [ 2.743823] fb: switching to nouveaufb from EFI VGA 727 [

Hi all, Sorry write to this list, here is the only place with a thread and a solution to this problem. At http://lists.xensource.com/archives/html/xen-devel/2007-09/msg00140.html you can read “ No, you simply don’t have a big enough swiotlb. The default is 2MB for a machine with less than 2GB of RAM, or 64MB for >2GB systems. “ All seen that for that guy that problem get solved changing the

Hi All, I have several ia32e systems with 8 gig that panic on install and first boot. The panic is arch/x86_64/swiotlb.c (working from memory so I might be a bit off) and its in the routine that I think is trying to allocate another chunk of memory for the "Software I/O Translation Buffer". I am guessing it needs to allocate contiguous chunks of memory and that is why it fails on the

Hi Jan, I''m curious about the status of your patches to make lib/swiotlb.c more Xen friendly. The ia64 port is currently using the hacked up swiotlb in the i386 directory, and it''s making it difficult to enable machine vectors to support hardware iommus. From what I can gather, several of the smaller patches are now in upstream Linux, but the larger abstraction patch got

The linux-2.6-xen tree has a typo in the Kconfig file for i386 that disables building swiotlb. This patch fixes it in the same manner that x86-64 does it. Cheers, Muli Signed-Off-By: Muli Ben-Yehuda <mulix@mulix.org> diff -r c1c170a55fe0e97156379d10870aed024ed0012a arch/i386/Kconfig --- a/arch/i386/Kconfig Thu Dec 8 20:50:02 2005 -0700 +++ b/arch/i386/Kconfig Tue Dec 13 20:07:34 2005

On 12/18/17 7:06 PM, Mike Galbraith wrote: > Greetings, > > Kernel bound workloads seem to trigger the below for whatever reason. >  I only see this when beating up NFS.  There was a kworker wakeup > latency issue, but with a bandaid applied to fix that up, I can still > trigger this. Hi, i have seen this one as well with my system, but i could not find an easy way to

On Tue, Dec 19, 2017 at 8:45 AM, Christian König <ckoenig.leichtzumerken at gmail.com> wrote: > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: >> >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: >>> >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: >>>> >>>> On 12/18/17 7:06 PM, Mike Galbraith wrote: >>>>>

On 2017-12-19 11:37 AM, Michel Dänzer wrote: > On 2017-12-18 08:01 PM, Tobias Klausmann wrote: >> On 12/18/17 7:06 PM, Mike Galbraith wrote: >>> Greetings, >>> >>> Kernel bound workloads seem to trigger the below for whatever reason. >>>   I only see this when beating up NFS.  There was a kworker wakeup >>> latency issue, but with a bandaid