linux-kernel - Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]

Open Source and information security mailing list archives

Message-ID: <20150416184252.GE7388@x230.dumpdata.com>
Date:	Thu, 16 Apr 2015 14:42:52 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Dorian Gray <yourfavouritegod@...il.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Suman Tripathi <stripathi@....com>,
	iommu@...ts.linux-foundation.org,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Error: DMA: Out of SW-IOMMU space [was: External USB drives
 become unresponsive after few hours.]

On Thu, Apr 16, 2015 at 06:57:46PM +0200, Dorian Gray wrote:
> On 16 April 2015 at 16:15, Alan Stern <stern@...land.harvard.edu> wrote:
> > This appears to be a problem with the IOMMU or SWIOTLB subsystems, not
> > the USB subsystem.  I have CC'ed the appropriate mailing lists.
> 
> Thanks, I'm far from being a kernel expert, so was expecting it could
> be wrong subsection.
> 
> 
> 
> On 16 April 2015 at 16:24, Suman Tripathi <stripathi@....com> wrote:
> > Try increasing the SWIOTLB size to 128MB .Default is 64MB.
> 
> Ok, so I'm back to k3.18.7 (default in the latest Fatdog), although
> I'm not sure what should be the exact value of swiotlb boot param?
> Got totally mixed results from uncle Google - some says the unit is in
> MiB, some that it's 4k pages and another that 128MiB = 65536, so I
> played it safe and used swiotlb=131072.
> Is this correct?
> It may take a few days, but I'll let you know if it worked (or for how
> long, if not).
> 
> 
> 
> On 16 April 2015 at 16:54, Alexander Duyck <alexander.duyck@...il.com> wrote:
> > More likely would be a device driver that is DMA mapping memory but not
> > unmapping it after it is done resulting in the bounce buffer pool being
> > depleted.
> > You might want dump the list of drivers loaded on the system with lsmod,
> > and then possibly look at doing a git bisect for something introduced
> > between 3.17 and 3.18 since that seems to be when you started seeing
> > this issue.
> 
> Ok, I'll (try to) look at this, but like I said - I'm not a kernel
> (nor git) expert.
> Anyway, I guess I'm gonna start with this:
> https://wiki.gentoo.org/wiki/Kernel_git-bisect
> Who knows...perhaps I'll find something...

And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
and then load the attached module.

That should tell you who and what else is holding on the buffers.

> 
> 
> 
> Thank you all for the replies.
> Jake
> _______________________________________________
> iommu mailing list
> iommu@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

View attachment "dump_dma.c" of type "text/plain" (1617 bytes)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives