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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Apr 2015 18:57:46 +0200
From:	Dorian Gray <yourfavouritegod@...il.com>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Suman Tripathi <stripathi@....com>
Cc:	USB list <linux-usb@...r.kernel.org>,
	iommu@...ts.linux-foundation.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 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...

Thank you all for the replies.
Jake
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/