similar to: [vhost:linux-next 2/23] include/linux/swiotlb.h:99:22: error: static declaration of 'swiotlb_max_mapping_size' follows non-static declaration

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 104f89a60ef5ec77d6f559eac4676844b3480740 commit: 155fcd8511de5f99c27a726e9153b87cce528b6e [3/23] swiotlb: Add is_swiotlb_active() function config: i386-tinyconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: git checkout 155fcd8511de5f99c27a726e9153b87cce528b6e #

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

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/

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:

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 >

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)

Hi Srivatsa, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on xen-tip/linux-next linus/master v5.7-rc3 next-20200428] [cannot apply to swiotlb/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base

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>

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

On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith <efault at gmx.de> wrote: > On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: >> 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:

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

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